PulseAudio & ALSA

[ludo@gnu.org (Ludovic Courtès)]

Ricardo Wurmus <rekado@elephly.net> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> skribis:
>>
>>> I’m not using pulseaudio; for me it’s just ALSA for regular software +
>>> JACK for “professional” audio where sync and timing matters.
>>
>> That’s what I expected.  ;-)
>>
>>> I’m not very knowledgeable about pulseaudio, unfortunately.  As
>>> pulseaudio can manage audio streams using various different backends
>>> from pulseaudio-agnostic software, what really is to be gained by adding
>>> pulseaudio to the inputs?  AFAIK using pulseaudio directly is not much
>>> different from using ALSA and configuring pulseaudio to manage this
>>> stream.
>>
>> As you note, the main difference is configuration.  For ALSA-lib to use
>> PulseAudio, one has to drop the relevant ~/.asoundrc, but it seems that
>> it does not always work properly.
>>
>> For instance, my ~/.asoundrc reads this:
>>
>> --8<---------------cut here---------------start------------->8---
>> # FIXME: alsamixer & co. from alsa-utils don't support it.
>>
>> pcm.!default {
>>     type pulse
>> }
>>
>> # ctl.!default {
>> #     type pulse
>> # }
>> --8<---------------cut here---------------end--------------->8---
>>
>> I don’t recall the details of the FIXME and the commented-out part,
>> though.
>>
>> For GuixSD I think it would be best if everything would automatically go
>> through PulseAudio, without the user having to configure obscure things.
>
> Couldn’t we then just install the appropriate /etc/asound.conf (maybe
> with a “pulseaudio-alsa” service)?  Users could still overwrite it by
> disabling the service or with “~/.asoundrc”.
>
> A similar configuration is provided on Arch by the “pulseaudio-alsa”
> package, which should be sufficient to route all ALSA audio streams
> through Pulseaudio.

Sounds like a good idea.

> Wouldn’t that be a better solution than to add the pulseaudio package to
> the inputs wherever possible?

Dunno.  It seems to me that applications that are PA-aware can have
better integration, like have their name shown in pavucontrol and
similar interfaces, which is quite useful.

There are also technical complications: alsa-lib must be able to find
its PulseAudio plug-in (currently we don’t build it since alsa-lib would
depend on PulseAudio), and it must be one that can actually be dlopened
by every process out there (linked against the same libc, etc.)

Thanks,
Ludo’.