Comment 194 for bug 371897

Is there any hope that the list of DONTS in Scott Richies bug report:
   http://bugs.winehq.org/show_bug.cgi?id=18740

And the analysis of Roderick Colenbrander in
   http://www.winehq.org/pipermail/wine-devel/2009-June/076112.html

brings Wine any further on this topic?

"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
"