Date: Fri, 9 Jun 2000 14:11:29 -0500 From: "Richard Seaman, Jr." <dick@tar.com> To: Brian Somers <brian@Awfulhak.org> Cc: Maxim Sobolev <sobomax@FreeBSD.org>, Kenneth Wayne Culver <culverk@wam.umd.edu>, Chris Piazza <cpiazza@jaxon.net>, Cameron Grant <cg@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, brian@hak.lan.Awfulhak.org Subject: Re: cvs commit: src/sys/dev/sound/pcm channel.c Message-ID: <20000609141129.A566@tar.com> In-Reply-To: <200006091630.RAA01120@hak.lan.Awfulhak.org>; from brian@Awfulhak.org on Fri, Jun 09, 2000 at 05:30:50PM %2B0100 References: <dick@tar.com> <200006091630.RAA01120@hak.lan.Awfulhak.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jun 09, 2000 at 05:30:50PM +0100, Brian Somers wrote: > > Sorry, I didn't mean to imply that the change "fixed" things. Its still > > broken here too, with the patch. But, with the patch I can at least > > get "sound" to play, but its garbled. Without it, sound playing shuts down > > in a few seconds. > > Ah, ok. > > Just FYI (to give you an idea of how I'm failing) > > If I just cat a .au file into /dev/audio, I get about 1/4 of a second > of plan and then silence, with & without the patch. Your symptoms are different then. Don't know if the cause is the same. What I've discovered so far is that chn_wrintr (in channel.c) is not getting called upon completion of a dma transfer during play, as the comments at the start of channel.c imply it should. As a result, the dma buffer pointers are not always properly updated. The dma buffer pointer b->rl goes progressively more negative, ultimately growing to a negative value many times the buffer size itself (this is with the extra chn_dmaupdate call as suggested in my patch). What I think happens without the extra chn_dmaupdate, dma buffer pointers are incremented when the device is written to (ie played). As soon as the total write equals the dma buffer, the buffer appears full, and sound playing stops. When the extra chn_dmaupate is inserted (as in the patch), it will get called when the device is written to, and the dma buffer pointers will be updated to reflect dma activity. But this only occurs when the device is written to, and not at completion of the dma transfer. It appears that the hardware dma pointer keeps incrementing, and if there is a delay in writing to the device, the hardware will walk past the end of the "ready" portion" of the dma buffer. At this point, the buffer pointers get messed up, and the sound gets garbled. Debug logs when the device is opened and during initial play (ok): Jun 9 12:51:13 test /kernel: open snd0 subdev 0 flags 0x00000005 mode 0x00002000 Jun 9 12:52:10 test /kernel: open snd0 subdev 4 flags 0x00000002 mode 0x00002000 Jun 9 12:52:10 test /kernel: open snd0 subdev 0 flags 0x00000003 mode 0x00002000 Jun 9 12:52:10 test /kernel: write snd0 subdev 4 flag 0x00020001 Jun 9 12:52:10 test /kernel: chn_wrintr Jun 9 12:52:10 test /kernel: buf 0x0xc19d8c40 ISA DMA started Jun 9 12:52:10 test /kernel: write snd0 subdev 4 flag 0x00030001 Jun 9 12:52:10 test /kernel: write snd0 subdev 4 flag 0x00040001 Jun 9 12:52:10 test /kernel: write snd0 subdev 4 flag 0x00050001 [snip] And then (ok): Jun 9 12:52:34 test /kernel: write snd0 subdev 4 flag 0x007e0001 Jun 9 12:52:35 test /kernel: write snd0 subdev 4 flag 0x007f0001 Jun 9 12:52:59 test last message repeated 120 times [snip] And then, garbled sound at this: Jun 9 12:54:32 test /kernel: OUCH!(0) rl -1244(14444) delta 15688 bufsize 65280 hwptr 53724 rp 53724(38036) Jun 9 12:54:32 test /kernel: write snd0 subdev 4 flag 0x007f0001 Jun 9 12:54:40 test last message repeated 38 times Jun 9 12:54:40 test /kernel: OUCH!(1) rl -140(8328) delta 8468 bufsize 65280 hwptr 41100 rp 41100(32632) [snip] Or worse: Jun 9 12:58:48 test /kernel: write snd0 subdev 4 flag 0x007f0001 Jun 9 12:58:48 test /kernel: OUCH!(96) rl -4560(1208) delta 5768 bufsize 65280 hwptr 4560 rp 4560(64072) Jun 9 12:58:48 test /kernel: write snd0 subdev 4 flag 0x007f0001 Jun 9 12:58:48 test /kernel: OUCH!(97) rl -6480(1840) delta 8320 bufsize 65280 hwptr 12880 rp 12880(4560) Jun 9 12:58:48 test /kernel: write snd0 subdev 4 flag 0x007f0001 Jun 9 12:58:48 test /kernel: OUCH!(98) rl -5836(-80) delta 5756 bufsize 65280 hwptr 18636 rp 18636(12880) Jun 9 12:58:48 test /kernel: write snd0 subdev 4 flag 0x007f0001 Jun 9 12:58:48 test /kernel: OUCH!(99) rl -5520(564) delta 6084 bufsize 65280 hwptr 24720 rp 24720(18636) Jun 9 12:58:49 test /kernel: write snd0 subdev 4 flag 0x007f0001 Jun 9 12:58:49 test /kernel: OUCH!(100) rl -5200(880) delta 6080 bufsize 65280 hwptr 30800 rp 30800(24720) Jun 9 12:58:49 test /kernel: write snd0 subdev 4 flag 0x007f0001 Jun 9 12:58:49 test /kernel: OUCH!(101) rl -4560(1200) delta 5760 bufsize 65280 hwptr 36560 rp 36560(30800) Jun 9 12:58:49 test /kernel: write snd0 subdev 4 flag 0x007f0001 Jun 9 12:58:49 test /kernel: OUCH!(102) rl -6164(1840) delta 8004 bufsize 65280 hwptr 44564 rp 44564(36560) Jun 9 12:58:49 test /kernel: write snd0 subdev 4 flag 0x007f0001 Jun 9 12:58:49 test /kernel: OUCH!(103) rl -5844(236) delta 6080 bufsize 65280 hwptr 50644 rp 50644(44564) Jun 9 12:58:49 test /kernel: write snd0 subdev 4 flag 0x007f0001 Jun 9 12:58:49 test /kernel: OUCH!(104) rl -5524(556) delta 6080 bufsize 65280 hwptr 56724 rp 56724(50644) Or later still: Jun 9 14:08:19 test /kernel: write snd0 subdev 4 flag 0x007f0001 Jun 9 14:08:19 test /kernel: OUCH!(20908) rl -281876(-276128) delta 5748 bufsize 65280 hwptr 46356 rp 46356(40608) Jun 9 14:08:19 test /kernel: write snd0 subdev 4 flag 0x007f0001 Jun 9 14:08:19 test /kernel: OUCH!(20909) rl -283476(-275476) delta 8000 bufsize 65280 hwptr 54356 rp 54356(46356) Jun 9 14:08:19 test /kernel: write snd0 subdev 4 flag 0x007f0001 Jun 9 14:08:19 test /kernel: OUCH!(20910) rl -283156(-277076) delta 6080 bufsize 65280 hwptr 60436 rp 60436(54356) Jun 9 14:08:19 test /kernel: write snd0 subdev 4 flag 0x007f0001 Jun 9 14:08:19 test /kernel: OUCH!(20911) rl -282836(-276756) delta 6080 bufsize 65280 hwptr 1236 rp 1236(60436) From dmesg: Jun 9 12:50:35 test /kernel: gusc0: <Gravis UltraSound Plug & Play PCM> at port 0x220-0x22f,0x320-0x327,0x32c-0x32f irq 11 drq 5,7 on isa0 Jun 9 12:50:35 test /kernel: pcm0: <GUS CS4231> on gusc0 $ cat /dev/sndstat FreeBSD Audio Driver (newpcm) Jun 9 2000 09:51:53 Installed devices: pcm0: <GUS CS4231> at io 0x32c irq 11 drq 7:5 (1p/1r channels duplex) $ uname -a FreeBSD test.tar.com 5.0-CURRENT FreeBSD 5.0-CURRENT #5: Fri Jun 9 12:45:49 CDT 2000 dick@test.tar.com:/usr/src/sys/compile/DS i386 -- Richard Seaman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 262-367-5450 Nashotah WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000609141129.A566>