Make pulseaudio the default alsa device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2016-10-21 at 11:24 -0300, Felipe Sateler wrote:
> On 21 October 2016 at 10:22, Tanu Kaskinen <tanuk at iki.fi> wrote:
> > 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.

When debugging pulseaudio problems, the first step is often disabling
autospawning so that pulseaudio can be started manually. If alsa
applications start to use the hardware directly in this situation,
that's not particularly helpful. (However, to be honest, I don't
remember actually experiencing this problem when debugging.)

If pulseaudio is seriously malfunctioning, it would be nice to get a
bug report, which is less likely if there's a fallback to skip
pulseaudio.

I think these are sensible reasons to not want an automatic fallback,
but I also acknowledge that it's entirely reasonable to prefer having
the fallback.

> > 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.

I would guess that there's no support for that. Such support could
probably be added reasonably easily, though.

> > 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.

If you don't want to work on the script that enables/disables
pulseaudio, it seems to me that the best way forward would be to move
the configuration file that you're currently using from the pulseaudio
package to alsa-plugins-pulseaudio-conf, and submit it to alsa-plugins
upstream.

-- 
Tanu


[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux