Christopher Allan Webber <cweb...@dustycloud.org> writes: > Ludovic Courtès writes: > >> Leo Famulari <l...@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
