http://bugs.winehq.org/show_bug.cgi?id=10495
--- Comment #89 from volker.groeschel@sap.com 2009-06-02 08:31:31 --- 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 "