tor, 06.05.2004 kl. 20.15 skrev James Courtier-Dutton: > I have been updating the wine alsa driver to work better with alsa. > So far, all I have done is update it to use the new alsa api. > Windows uses an api called Direct Sound.
I think this problem has been discussed on this list before, with WineX's version of winealsa delivering good performance as a result. You can see the current code at http://cvs.transgaming.org/cgi-bin/viewcvs.cgi/winex/dlls/winmm/winealsa/ and http://cvs.transgaming.org/cgi-bin/viewcvs.cgi/winex/dlls/dsound/ (there are some changes to how the mixer thread puts changes into the primary buffer, specifically the primary buffer is locked/unlocked before data is written to it) TransGaming is currently willing to donate at least the winealsa parts to ReWind and Wine under the MIT license, so you should be able to merge any winealsa changes you like into Wine. > Direct Sound uses direct hardware buffer access. If possible. It can do without. > A Win32 program can quiry the sound driver and ask for the currently > playing position, together with the first available possition that the > application could write to. I will call these "PlayPos" and "WritePos" > respectively. > E.g. If the hardware is halfway through playing one period(the PlayPos > is in the middle of a period), the beginning of the next period's > position is returned as the "WritePos". > > The problem arrives because the Win32 app expects to have full write > access to the hardware buffer, and can write to any parts of it at any > time. Well, not exactly at any time. It must lock the portion it wants to write to first. But perhaps you're talking about not the Win32 app, but Wine's mixer thread. This thread should also lock the primary buffer; not doing so is a bug, which is now fixed in WineX. This would allow operation where the software mixer does not write to the hardware buffer, but the driver transfers the data there upon unlock, without most of the problems associated with using a pcm callback that attempts to copy data just in time. It even allows operation where the software mixer *does* write directly to the hardware buffer... And when the mixer thread does the proper locking, then the driver's Lock/Unlock calls can be implemented in terms of ALSA's mmap_begin and mmap_commit calls, it just takes some juggling with the application frame pointer. And you end up as close to the hardware as you need to be, without using a PCM callback. Using this design, WineX's winealsa seems to perform about as well as wineoss. > The sound card should just happily move through the buffer playing > each sample as it goes, and when it reaches the end, just start at the > beginning again. The set_stop_threshold call in WineX's winealsa kinda lets the card do this (thanks Jaroslav). > Another problem is that if I want to stop the stream, I call > "snd_pcm_drop(). With this I would expect snd_pcm_delay()==0 and > snd_pcm_avail_update()==buffer_size. > It seems that these values are only reset to 0 after first calling > snd_pcm_prepare(). > After stopping the stream in this way, I want to restart it again > without having to close/open the pcm. Well, the solution is pretty simple. After calling snd_pcm_drop(), just call snd_pcm_prepare(). Works for us. ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
