Re: PulseAudio

[Ricardo Wurmus <rekado@elephly.net>]

Christopher Allan Webber <cwebber@dustycloud.org> writes:

> Ludovic Courtès writes:
>
>> Leo Famulari <leo@famulari.name> skribis:
>>
>>> I guess the factors are:
>>> 1) Does GuixSD have a default audio setup that we should target? If
>>> GuixSD uses PulseAudio, then I think it would be good for eSpeak to be
>>> integrated into that sytem.
>>> 2) Does this package, which launches PulseAudio, work for anyone on a
>>> foreign distro?
>>
>> It’s not written anywhere, but I think most of our audio packages target
>> PulseAudio (that’s what I use on GuixSD.)  I’m in favor of consistently
>> using it, and it would probably be best to write it down in the manual.
>>
>> Thoughts?
>>
>> Ludo’.
>
> I'd really like it if we just agreed that in general, yeah, we want
> Pulseaudio support.

I agree with Pulseaudio *support*, but this does not mean that we’d have
to link all applications that have an optional Pulseaudio backend with
the Pulseaudio libraries, does it?

Since I’m not using Pulseaudio I cannot vouch for this to work, but ALSA
can be configured to use redirect audio streams to Pulseaudio (if it’s
running).  I know of no application that offers a Pulseaudio backend but
cannot use ALSA directly.  This redirection from ALSA to Pulseaudio
could be implemented as an etc-service, providing the required
configuration file.

My experience with Pulseaudio was very different (and still is if I
count support requests from friends), but maybe that’s just because I
don’t *always* want Pulseaudio.  I found it difficult to reliably
disable/suspend Pulseaudio whenever I wanted to do audio work (=
involving JACK).  It often just got in the way.

On other machines where I didn’t use JACK regularly Pulseaudio was
acceptable, I guess.  It makes me shed a salty tear that something so
complicated and layered as Pulseaudio was necessary to tame the mess in
the Linux [sic] audio world :-/

~~ Ricardo