[Bug 18740] New: Use of "unsafe" subset of ALSA causes problems with PulseAudio
http://bugs.winehq.org/show_bug.cgi?id=18740 Summary: Use of "unsafe" subset of ALSA causes problems with PulseAudio Product: Wine Version: 1.1.22 Platform: PC URL: http://0pointer.de/blog/projects/guide-to-sound-apis.h tml OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: scott(a)open-vote.org Blocks: 10910 http://0pointer.de/blog/projects/guide-to-sound-apis.html If we want PulseAudio to work well, we have to limit ourselves to the safe subset of the ALSA API. DONTS: * Do not use "async handlers", e.g. via snd_async_add_pcm_handler() and friends. Asynchronous handlers are implemented using POSIX signals, which is a very questionable use of them, especially from libraries and plugins. Even when you don't want to limit yourself to the safe ALSA subset it is highly recommended not to use this functionality. Read this for a longer explanation why signals for audio IO are evil. * Do not parse the ALSA configuration file yourself or with any of the ALSA functions such as snd_config_xxx(). If you need to enumerate audio devices use snd_device_name_hint() (and related functions). That is the only API that also supports enumerating non-hardware audio devices and audio devices with drivers implemented in userspace. * Do not parse any of the files from /proc/asound/. Those files only include information about kernel sound drivers -- user-space plugins are not listed there. Also, the set of kernel devices might differ from the way they are presented in user-space. (i.e. sub-devices are mapped in different ways to actual user-space devices such as surround51 an suchlike. * Do not rely on stable device indexes from ALSA. Nowadays they depend on the initialization order of the drivers during boot-up time and are thus not stable. * Do not use the snd_card_xxx() APIs. For enumerating use snd_device_name_hint() (and related functions). snd_card_xxx() is obsolete. It will only list kernel hardware devices. User-space devices such as sound servers, Bluetooth audio are not included. snd_card_load() is completely obsolete in these days. * Do not hard-code device strings, especially not hw:0 or plughw:0 or even dmix -- these devices define no channel mapping and are mapped to raw kernel devices. It is highly recommended to use exclusively default as device string. If specific channel mappings are required the correct device strings should be front for stereo, surround40 for Surround 4.0, surround41, surround51, and so on. Unfortunately at this point ALSA does not define standard device names with channel mappings for non-kernel devices. This means default may only be used safely for mono and stereo streams. You should probably prefix your device string with plug: to make sure ALSA transparently reformats/remaps/resamples your PCM stream for you if the hardware/backend does not support your sampling parameters natively. * Do not assume that any particular sample type is supported except the following ones: U8, S16_LE, S16_BE, S32_LE, S32_BE, FLOAT_LE, FLOAT_BE, MU_LAW, A_LAW. * Do not use snd_pcm_avail_update() for synchronization purposes. It should be used exclusively to query the amount of bytes that may be written/read right now. Do not use snd_pcm_delay() to query the fill level of your playback buffer. It should be used exclusively for synchronisation purposes. Make sure you fully understand the difference, and note that the two functions return values that are not necessarily directly connected! * Do not assume that the mixer controls always know dB information. * 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. * Do not assume that snd_pcm_rewind() is available and works and to which degree. * Do not assume that the time when a PCM stream can receive new data is strictly dependant on the sampling and buffering parameters and the resulting average throughput. Always make sure to supply new audio data to the device when it asks for it by signalling "writability" on the fd. (And similarly for capturing) * Do not use the "simple" interface snd_spcm_xxx(). * Do not use any of the functions marked as "obsolete". * Do not use the timer, midi, rawmidi, hwdep subsystems. DOS: * Use snd_device_name_hint() for enumerating audio devices. * Use snd_smixer_xx() instead of raw snd_ctl_xxx() * For synchronization purposes use snd_pcm_delay(). * For checking buffer playback/capture fill level use snd_pcm_update_avail(). * Use snd_pcm_recover() to recover from errors returned by any of the ALSA functions. * If possible use the largest buffer sizes the device supports to maximize power saving and drop-out safety. Use snd_pcm_rewind() if you need to react to user input quickly. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18740 Dmitry Timoshkov <dmitry(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement --- Comment #1 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2009-06-01 22:24:53 --- I'd say that if PulseAudio has such a long list of restrictions (which ALSA apparently doesn't have), it's broken, and should be fixed on PulseAudio side instead. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18740 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source --- Comment #2 from Austin English <austinenglish(a)gmail.com> 2009-06-01 22:44:01 --- How is this a wine bug? Pulseaudio is supposed to work without any extra effort on our end... -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18740 --- Comment #3 from Saulius K. <saulius2(a)gmail.com> 2009-06-02 00:35:39 --- * With regard to comment #1 From Dmitry Timoshkov: | | I'd say that if PulseAudio has such a long list of restrictions (which ALSA | apparently doesn't have), it's broken, and should be fixed on PulseAudio side | instead. Dmitry, can you confirm writing eg. ASIO drivers in Windows wasn't put under similar restrictions? If you don't, then enumerate ones which breaks the systemicity of the design Wine implements, please. Or theoretically prove PulseAudio could be fixed/designed in other way. I strongly believe the list got long due to trivial and acceptable reasons: * changes in appropriate APIs; * old linux kernels (configurations) being uncapable of handling low-latency audio processing; * old/odd hardware restricting software in a similar way. I take the list as just another, renewed guide to coding glitch-free ALSA sound processing. * With regards to comment #2 From Austin English: | | Pulseaudio is supposed to work without any extra effort on our end... And who was the supposer then? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18740 Adys <adys.wh+winehqdotorg(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adys.wh+winehqdotorg(a)gmail. | |com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18740 --- Comment #4 from Austin English <austinenglish(a)gmail.com> 2009-06-02 02:35:19 --- (In reply to comment #3)
* With regards to comment #2 From Austin English: | | Pulseaudio is supposed to work without any extra effort on our end...
And who was the supposer then?
See bug 10495 for a long discussion on that. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18740 Dmitry Timoshkov <dmitry(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #5 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2009-06-02 05:04:27 --- Let's mark it a duplicate then, leaving an exercise to prove that it's a Wine fault to Pulse developers. *** This bug has been marked as a duplicate of bug 10495 *** -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18740 Dmitry Timoshkov <dmitry(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #6 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2009-06-02 05:07:32 --- Closing duplicate. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18740 Aigars Mahinovs <aigarius(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aigarius(a)gmail.com --- Comment #7 from Aigars Mahinovs <aigarius(a)gmail.com> 2009-06-17 01:53:08 --- This is not a duplicate - Wine uses an unsafe subset of ALSA API that actively hinders cooperation with other sofware. This has nothing to do with bug 10495 which is a wishlist bug asking to create an output driver to Pulseaudio. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18740 Scott Ritchie <scott(a)open-vote.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |REOPENED Resolution|DUPLICATE | --- Comment #8 from Scott Ritchie <scott(a)open-vote.org> 2009-06-17 02:08:03 --- I tend to agree with keeping this as a separate bug - even if we don't want to support PulseAudio, sticking to the safe subset of ALSA has advantages anyway, such as making the code more future proof and portable. As I understand it, the unsafe portions of the ALSA API don't work on every ALSA system anyway. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18740 Dmitry Timoshkov <dmitry(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |DUPLICATE --- Comment #9 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2009-06-17 02:09:30 --- This IS a duplicate, please don't reopen. *** This bug has been marked as a duplicate of bug 10495 *** -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18740 Dmitry Timoshkov <dmitry(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #10 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2009-06-17 02:10:22 --- Closing duplicate. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18740 --- Comment #11 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2009-06-17 02:14:35 --- Just for the reference: the bug 10495 is about better support for Pulse in Wine, regardless whether it's via a new driver, or a proposed set of fixes for existing audio infrastructure in Wine. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org