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
