[pulseaudio-discuss] Make pulseaudio the default alsa device

[Felipe Sateler]

On 21 October 2016 at 10:22, Tanu Kaskinen <tanuk at iki.fi> wrote:
>
> On Tue, 2016-10-18 at 09:59 -0300, Felipe Sateler wrote:
> > On 18 October 2016 at 06:50, Tanu Kaskinen <tanuk at iki.fi> wrote:
> > > If the system is configured to use pulseaudio, then I would prefer alsa
> > > applications to fail if pulseaudio isn't running, rather than falling
> > > back to whatever the default is if pulse-alsa.conf isn't loaded. It
> > > makes debugging easier.
> >
> >
> > I'm not sure if it makes sense to ask if "the system is configured to
> > use pulseaudio", because individual users on a system might
> > disable/enable it.
>
> Wouldn't per-user configuration be better suited for ~/.asoundrc? Now
> you're assuming that if pulseaudio isn't available for whatever reason,
> the user doesn't want to use pulseaudio. That's not always correct, but
> it might be correct often enough that it makes sense for you to do that
> instead of requiring users to modify ~/.asoundrc.

Because pulseaudio defaults to autospawn, if the daemon can't be
reached then for most users the current heuristic means either:

1. Pulseaudio has been manually disabled via `autospawn = no`.
2. Pulseaudio is seriously malfunctioning and can't start.

In either case I don't think it makes much sense to set the alsa
default device to pulseaudio.

>
> One alternative would be to create a program/script for
> disabling/enabling pulseaudio (which is nowadays annoyingly
> distribution specific, so a unifying script would be welcome even for
> this reason alone), which would also (optionally) set up the default
> device in ~/.asoundrc. That way there would be just one step for users
> to toggle between pulseaudio and plain alsa.

Does alsa support ~/.asoundrc.d or equivalent? Otherwise the script
would get hairy very fast.

>
> > > But if the Debian alsa maintainers prefer to
> > > fall back to non-pulseaudio configuration even when pulseaudio is
> > > installed, then it seems reasonable to propose this to alsa upstream.
> >
> >
> > This file is being shipped by pulseaudio, not alsa.
>
> (By "pulseaudio" you obviously mean the Debian package, not the
> upstream project.)

Yes, sorry if that confused anyone.

> Ok, so shipping this in pulseaudio upstream would be more convenient
> for Debian.

Yes :). Alternatively, I'm also happy to use an upstream-sanctioned
way to achieve the same. What I really want is for the debian package
to diverge as little as possible from upstream, but without degrading
user experience, of course.

> However, alsa-plugins already has a file that sets
> pulseaudio as the default device, and e.g. OpenEmbedded ships the
> configuration in alsa-plugins-pulseaudio-conf, which is a binary
> package generated from the alsa-plugins source.

This is an interesting approach. Debian package pulseaudio could
Recommends: alsa-plugins-pulseaudio-conf (this means install by
default, but allow uninstalling). The only problem I see is how to
disable per-user (via .asoundrc?). I have gotten requests to be able
to disable per-application, because some specific apps malfunction
with the pulse virtual device.

> Having two different but similar-in-purpose alsa configuration files in
> two upstream projects doesn't seem sensible, so either the existing
> file in alsa-plugins should be moved to pulseaudio, or you should try
> to upstream your configuration file to alsa-plugins.

Yes, the current situation is fairly confusing. To add to the
confusion, the debian pulseaudio package ships a copy of the
alsa-plugins configuration file :/

> I don't think
> either option is clearly better than the other (but as the OpenEmbedded
> alsa and pulseaudio maintainer I'd obviously prefer shipping the files
> in alsa-plugins, since that would be less work for me).

I think it makes sense that all alsa-pulse glue should belong in one package.

-- 

Saludos,
Felipe Sateler