Roderick Colenbrander wrote: > On Tue, Jun 2, 2009 at 10:08 AM, Francois Gouget <fgou...@free.fr> wrote: >> On Tue, 2 Jun 2009, Ben Klein wrote: >> >>> 2009/6/2 Scott Ritchie <sc...@open-vote.org>: >> [...] >>>> First, I talked with a Pulseaudio expert about what we can do to make >>>> things work better. He said that if we want good compatibility we will >>>> need our ALSA stack to use the Pulseaudio safe subset: >>>> http://0pointer.de/blog/projects/guide-to-sound-apis.html. I've filed a >>>> metabug tracking this here: >>>> http://bugs.winehq.org/show_bug.cgi?id=18740. Use of this unsafe subset >>>> can cause most problems with stuttering or even complete dropoff. >>> As far as I know, this is not possible for Wine (without massive >>> latency issues caused by overbuffering in Wine itself) due to the fact >>> that Wine has to make DirectSound apps happy. >> Which of the DONTs are causing problems for Wine? (And why?) >> It would be nice to identify them to be able to send argumented feedback >> to the PulseAudio developers. >> >> >> -- >> Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ >> tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY >> >> >> > > I have quickly checked the code and this are I think some of the > 'easy' DONTs we violate: > - we use snd_config_xxx(), this is replaceable by snd_device_name_hint() > - we use snd_card_xxx(), this can be replaced by snd_device_name_hint() > - we hard code device strings (e.g. plughw0) > - we use snd_pcm_avail_update and snd_pcm_delay > (there might be some more but those are less trivial to check) > > The most critical are the following: > - Do not assume that all devices support MMAP style buffer access. > - Do not assume that the hardware pointer inside the (possibly mmaped) > playback buffer is the actual position of the sample in the DAC. There > might be an extra latency involved. > - Do not try to recover with your own code from ALSA error conditions > such as buffer under-runs. Use snd_pcm_recover() instead. > - Do not touch buffering/period metrics unless you have specific > latency needs. Develop defensively, handling correctly the case when > the backend cannot fulfill your buffering metrics requests. Be aware > that the buffering metrics of the playback buffer only indirectly > influence the overall latency in many cases. i.e. setting the buffer > size to a fixed value might actually result in practical latencies > that are much higher. > > Especially the first one direct sound is all about direct card access > and hence mmap .. > > Roderick >
It would be very nice if we could meet PulseAudio at least half way here. So far we've essentially made a massive feature request for them: "do everything ALSA does" -- it would be much nicer (and much more likely to happen) if we could distill that down to just a few of the above points that are essential with good explanations as to why we have to do it that way. Thanks, Scott Ritchie