Date: Sun, 02 Apr 2000 18:11:23 +0300 From: Maxim Sobolev <sobomax@altavista.net> To: MIHIRA Sanpei Yoshiro <sanpei@sanpei.org> Cc: cg@FreeBSD.ORG, current@FreeBSD.ORG, multimedia@FreeBSD.ORG Subject: Buffering issues of the pcm audio driver (Was: cvs commit: src/sys/dev/sound/isa ess.c) Message-ID: <38E7631B.E06D3D70@altavista.net> References: <38E68B29.2055235C@altavista.net> <200004021437.XAA34730@lavender.yy.cs.keio.ac.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format. --------------42AABDBF5E5B30EDD5BCA01F Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: 7bit Hi, I've tried to track down sound issues of the SDL (Simple Direct Layer) library and found that current pcm buffering behaviour inconsistent with OSS specifications, which cause applications that require sophisticated sound control to misbehave on FreeBSD. There is two different buffers implemented in the pcm driver: one back-end, with size specified an a compile time (ranging from 4KB to 64KB on different chipsets), and one front-end size of which could be changed by the audio application at runtime. Problems arises when application tries to get current state of the audio buffer either by using select(), or by doing direct SNDCTL_DSP_GETOSPACE ioctl(). In both these cases current FreeBSD behaviour isn't consistent with OSS specs: - the SNDCTL_DSP_GETOSPACE ioctl() returns current state of the front buffer, while ignores much larger back buffer which usually absorbs all data sent to the pcm. Thus application using this ioctl() being fooled about how much data is in the audio buffers. - the select() call doesn't block until the whole back buffer will be filled, while according to specs it should block while fragsize*fragnumber amount of data already is in the buffers. Possible solution (from better to worse): 1. Fix select() support in the pcm driver to account effects of the two buffers. 2. Provide workaround to the SNDCTL_DSP_GETOSPACE to return largest free buffer space available in either front or back buffer. Thus aware applications would have a possibility to check how much data is in hardware buffers and behave accordingly. This will not violate OSS specs, as it is permitted to have this value larger than fragsize*fragments. See attached diffs. 3. Decrease size of the back buffers in all pcm drivers to a some reasonable value like 4KB. -Maxim --------------42AABDBF5E5B30EDD5BCA01F Content-Type: text/plain; charset=x-user-defined; name="dsp.c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dsp.c.diff" --- /usr/src/sys/dev/sound/pcm/dsp.c 2000/04/02 09:41:26 1.1 +++ /usr/src/sys/dev/sound/pcm/dsp.c 2000/04/02 09:49:56 @@ -467,8 +467,8 @@ chn_checkunderflow(wrch); while (chn_wrfeed(wrch) > 0); } - a->bytes = bs->fl; - a->fragments = a->bytes / wrch->blocksize2nd; + a->bytes = (bs->fl > b->fl ? bs->fl : b->fl); + a->fragments = bs->fl / wrch->blocksize2nd; a->fragstotal = bs->bufsize / wrch->blocksize2nd; a->fragsize = wrch->blocksize2nd; } --------------42AABDBF5E5B30EDD5BCA01F-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38E7631B.E06D3D70>