Date: Sun, 02 Apr 2000 02:50:01 +0300 From: Maxim Sobolev <sobomax@altavista.net> To: Cameron Grant <cg@FreeBSD.ORG> Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/dev/sound/isa ess.c Message-ID: <38E68B29.2055235C@altavista.net> References: <200004012128.NAA87299@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Cameron Grant wrote: > cg 2000/04/01 13:28:10 PST > > Modified files: > sys/dev/sound/isa ess.c > Log: > bump the buffer size from 4k to 16k. should improve performance under load. ... and worsen audio synchronization in apps using modern multithreaded multimedia libraries like SDL. In general is there is any objections to violate OSS specs by specifying buffer size at a compile time, rather than to manage it dynamically? There will always be tradeoff between high quality and high resolution data like mp3, which is sensitive to skips but not very sensitive to delays, and realtime low quality and low resolution games data, which in turn not very sensitive to skips, but very sensitive to delays. I've stuck into this problem on my OPL3-SA based soundcard, where 64KB (!!!) buffer provided by default, while apps trying to get from driver much less buffer space (usually up to 1K). For example, all games using the SDL library was fouled thinking that buffer is empty (as the select() suggested so) and keeping pumping data into there until it completely filled those famous 64KB, which on 22KHz turns into 3 second delay in sound effects. I've even wrote testcase exposing this problem and ready to send it to anyone who want to look into this problem. -Maxim 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?38E68B29.2055235C>