Date: Wed, 18 Feb 1998 08:21:24 +0100 (MET) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: gljohns@bellsouth.net (Glenn Johnson) Cc: multimedia@FreeBSD.ORG Subject: Re: pcm0 and xgalaga Message-ID: <199802180721.IAA02190@labinfo.iet.unipi.it> In-Reply-To: <199802180612.AAA00914@gforce.bellsouth.net> from "Glenn Johnson" at Feb 18, 98 00:11:45 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Greeting, > > I just tried the new pcm0 sound code in 2.2.5-STABLE. The sounds are delayed a > few seconds in xgalaga. When I first start playing, I don't hear any sound. > Then about 9 seconds into the game, I hear the sounds but they are not > synchronized with the events. After I quit the game, I then hear the sounds this problem usually occurs because the application tries to set a small amount of buffering B in the device driver (a request that the pcm driver does not honor at the moment). Then the program sets non blocking mode and does not check for short writes, having the guarantee that it cannot be more than B/sample_rate behind. This is actually not so simple because when you write some sound you still want that the amount of data written is long enough to recognize the sound, or you'll just hear noise. So a hard limit is not exactly what you want, a low-water/high-water mechanism would be much more appropriate. I have no idea what is implemented by Voxware. 9 sec. correspond to abut 64KB at 8 Ks/s which is exactly the buffer size in the pcm driver. From your description of the problem it might be that xgalaga tries to keep the buffer full by writing silence every so often, followed by sounds whenever it needs to. The possible fixes are: 1) complete the SETFRAGMENT (or whatever it is called) implementation (not hard, you just need to reduce the blocksize in the dma buffer descriptor and reset the dma channel; 2) fix the application to be able to deal with bigger buffers (i.e. check the amount of data buffered in the driver and then decide how much to write). Right now there is the AIONWRITE ioctl which tells you how much data can be written without blocking; together with AIOGCAP, which tells you the amount of buffering, you can know how much data is queued. Then you can implement the low/hi water mechanism as described above. #2 is easier since it is only something to do in the application. #1 would be useful to all games using the same strategy (but beware, i have report of some games producing just noise on a fast machine because too few samples of each sound are written). So i think the best option would be to do both things. let me know if you need help with the coding. cheers luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ 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?199802180721.IAA02190>