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
