Date: Wed, 18 Feb 1998 22:18:51 -0600 From: Glenn Johnson <gljohns@bellsouth.net> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: multimedia@FreeBSD.ORG Subject: Re: pcm0 and xgalaga Message-ID: <199802190418.WAA02415@gforce.bellsouth.net> In-Reply-To: Your message of "Wed, 18 Feb 1998 08:21:24 %2B0100." <199802180721.IAA02190@labinfo.iet.unipi.it>
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 Well, xgalaga is just an occasional diversion for me but I will see what I can do with your suggestions. I do not consider myself much of a programmer so this could be a good learning experience. Thanks for your reply. -- Glenn Johnson gljohns@bellsouth.net 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?199802190418.WAA02415>