Hi, PA resamples everything, which is fine. However there should be a means to find out the rate that PA itself uses to drive the underlying device. By contrast, plug:dmix resamples everything too. Yet when I use snd_pcm_open("plug:dmix",0 , SND_PCM_NO_AUTO_RESAMPLE | SND_PCM_NO_AUTO_CHANNELS | SND_PCM_NO_AUTO_FORMAT) it becomes trivial to find out using e.g. snd_pcm_hw_params_get_rate that it is mixing at 48000 and solely accepts S32_LE. Currently, Wine does not manage to find out PA's rate. PA accepts each and every format despite the above flags. As a result, Wine uses 48000 which PA accepts and publishes this rate via the MMDevAPI interface. What then happens is that MS apps resample all their sounds to 48000 for mmdevapi, which passes that to ALSA->PA which resamples down to 44100 to drive the ALSA HW. That is a gratuitous waste of the HW owner's resources. Of course Wine could hard code 44100 when it detects "pulse", but that is a hack. Any user could launch PA at a different rate AFAIK. IMHO the alsa_plugins for PA should obey SND_PCM_NO_AUTO_* but I'm open for suggestions. How to detect PA's rate from the ALSA side? Thank you, Jörg Höhle
It appears that Chris Robinson of OpenAL fame is experiencing the same kind of problem: http://opensource.creative.com/pipermail/openal-devel/2012-February/005861.html > the ALSA backend doesn't do as good of a job > autodetecting the default output mode (eg, quad or 5.1 surround) Currently for Wine I'm mostly interested in the rate, but as Wine will look into multi-channel support past 1.4, getting the underlying number of channels will be equally important.
With dmix, I think the underlying sound card is selected already during snd_pcm_open(), am I right? The problem is then that the sound card is not selected yet at that point when using pulseaudio as the backend. The stream routing decision is done only at the time when the stream is created (I don't know exactly in which alsa function that is done, but surely not snd_pcm_open()). It sounds feasible to me, though, to open the Pulseaudio stream already in some earlier phase, if one or more NO_AUTO_FOO flags are given. Pulseaudio supports creating streams with "fixed" parameters, which means that the stream parameters will get set according to the sink that it is routed to. After the stream has been created, it's possible for the application to query the parameters. So that's my understanding of the reason why things don't currently work as you'd like, and a possible approach for fixing it. Does someone want to try writing a patch?
I don't suppose it would be possible to make the 'pulse' plugin always use PA's format, rate, and channels (excepting to make sure the channel order matches what ALSA would usually give, as ALSA has no way to specify this itself), and rely on the 'plug' plugin for format conversion, resampling, and remixing channels? In other words, apps would use "plug:pulse" (which should automatically obey the SND_PCM_NO_AUTO_* flags) to output to PulseAudio with any format/rate/channels, while just "pulse" would require float32 (or whatever is most efficient to give to the mixer), and whatever rate and channels are being used for the device. The "default" device override can use a plug->pulse chain to keep compatibility with apps that expect more formats/rates/channels. I think that would be best in keeping with ALSA's design, though I'm not sure if messing with the pulse plugin like that would be a problem. Another option may be to create the stream on snd_pcm_open with default settings, restrict the 'hardware configuration space' depending on the aforementioned flags, and recreate the stream when snd_pcm_hw_params is called with the new format. Just some ideas, anyway. Can't say I know enough about the internal workings of these things to know for sure the best way to go.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/298.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.