[pulseaudio-discuss] padevchooser improvements
gmane at colin.guthr.ie
Wed Nov 12 02:35:17 PST 2008
Michael Gratton wrote:
>> Do you know about tunnels?
> Nope! First I've heard of them. I don't follow PA development, so if
> there's no GUI for it and it wasn't announced on, say, Planet Gnome,
> then I probably missed it.
Well, as tunnels have been around for about as long as I've been using
pulse (several years) I doubt there would have been any recent
announcement about this!
>> Rather than use padevchooser to output the sound to a different
>> device, I'd personally use a tunnel rather than setting the system
>> wide defaults. I can then use pavucontrol to move the streams between
>> my local and remote devices at will. It's not overly easy to set the
>> default for *everything* this way tho', but it does have other
> That sounds good, but its not my use-case:
> At work, I want to redirect /all/ audio on my notebook to my workstation
> (where I have headphones plugged in) since I don't want my notebook
> making random noises and annoying other people throughout the day, but I
> still want to hear the audio myself (especially when playing tunes).
I'd still suspect that tunnels are the way to go in this use case too to
be honest, but perhaps with different routing rules (e.g. some rules to
say that *all* streams should be routed to the tunnel sink rather than
remembering which sink the app last used and reusing it). This should be
simple enough to incorporate.
>> Pulseaudio has automatic support for adding tunnels to network devices
>> via the module-zeroconf-discover which will load module-tunnel-sink
>> when it finds a pulseaudio server on the network. You can enable
>> zeroconf discovery with a few options in paprefs
> Yes, I've enabled that on both machines but it has never automatically
> connected the two together. Looking at the manager now I can see the
> tunnels and pavucontrol seems to displaying an extra set of sinks I can
> move a playback stream to, but they are completely ambiguous; I don't
> know which one to choose and it's not clear on the Output Devices tab,
For me it's quite obvious how they work. When I bring up the menu for a
running stream it, the submenu clearly says "Move Stream" and the device
names therein are formed out of the Avahi Zeroconf name.
That's not to say it couldn't be better. I'm sure Lennart would be open
to suggestions (tho' I can say for sure he'll be more appreciative of
patches, provided they make sense!)
> Further problems with pavucontrol are: You can only move streams that
> already exist,
Yeah this is true. It's kinda hard to move a stream for an app that
hasn't played yet of course :p, but I guess previous apps and their
routing could be displayed somehow.
This is not something that is currently exposed in the pulseaudio
protocol tho', and as pavucontrol is just a pulseaudio client, and
cannot (and should not) work on the config files etc. (as who is to say
the daemon that pavucontrol is connected to is local?).
To do this kind of thing would require further extension of the PA
protocol, and as such I'm not sure if this can be done short term. It
would certainly need Lennart's input before I'd recommend trying to code
redirecting an application's streams isn't sticky,
Yes it is. If it's not for you then somethings broken in your setup, but
it certainly does work in a sticky fashion.
> finding the application you want to move is annoying when you have many
> applications using sound and to choose a different default source/sink,
> you need to run pavucontrol, switch to the right tab and use pull down
> menu, making it impossible to see and set at a glance. That and the
> number and the ambiguity of the source/sink names are the real killers.
Again, I'm sure Lennart would appreciate any patches to the pavucontrol
program to make the interface more intuitive.
The names of the network sinks I personally don't have a problem with.
They are named after the machine's network address and the description
is fairly obvious too IMO, but if you can come up with a better way to
name them, it would be relatively simple to patch this in pulseaudio.
>>> This is what I'd propose:
>>> 1. Make padevchooser revert to the local machine when avahai
>>> reports the currently selected network server/source/sink has
>>> disappeared - this fixes the last problem above
>> With tunnels this happens automatically (and for running streams) via
>> the help of module-rescue-streams
> If you're using tunnels then that is fine. Is module-rescue-streams
> automatically enabled if you're using tunnels? Does it work if the
> default sink goes away?
No, it's nothing to do with tunnels per-se. It's just to do with sinks
(and tunnels are just another kind of sink). At the level this module
operates, it knows nothing about how this sink operates internally, it
could be a null-sink, a RAOP sink, a tunnel sink or a h/w sink.
When a sink disappears, (e.g. the network is removed, or a USB device is
unplugged), module-rescue-streams will take any running streams on that
device and move it to another one.
If there are no sinks left (e.g. nothing to play) module-always-sink
will actually kick in and load a null sink until a real sink is
available again. When a real sink does become available again (USB
plugged back in, network attached etc.), module-always-sink will unload
the null plugin and the streams will be rescued again by
module-rescue-streams and be moved to the real sink!
Both these modules are loaded as part of the default.pa (in /etc/pulse):
### Automatically move streams to the default sink if the sink they are
### connected to dies, similar for sources
### Make sure we always have a sink around, even if it is a null sink.
>> A lot of what you describe here should really be handled in pulseaudio
> While the internals for moving/recovering streams can and should, I
> don't think the user experience side of it can. What if there are
> multiple machines advertising network sinks? What if you don't want to
> automatically connect to an advertised sink? There needs to be some
> manual way of moving some or all streams around, pavucontrol might be
> fine for intermittent use by technical people, but it is not if you are
> non-technical or need to use it every day.
Ahhh I have plans for that... see below.
>> It's great that you're interested but I think you should not use
>> padevchooser as a starting point.
> So what's the alternative? I'd love to have a notification icon that
> shows up when network hosts appear, that lets me (easily) switch the
> default sink to a different network host when available and ensures
> fall-back to the local host when the other goes away.
Indeed... part of the plan mentioned above... see below.
> Autoconnection would be nice but it needs to do the right thing in the
> face of multiple available hosts and needs to be able to be manually
I've got a plan for this part and while it may not be the ultimate
solution, I personally think it's the way forward.
I've started work (stalled for now) on a notification framework for
pulse. A module can register itself as handling these notifications and
display popups with options on them (basically via libnotify for now,
but a KDE "notifier" module would be possible too; and there is nothing
to stop a synthesised voice with voice input notifier being written if
you are that way inclined!!).
This system would allow for the various modules to let the user know
something happend or request user feedback.
e.g. a popup that said:
Detected Network Sink on "hostname" Do you want to use this device?
[ No ] [ Yes ] [ Yes and set it as default ]
> Should this be a new program since padevchooser is deprecated? Could it
> be integrated into a cleaned-up version of pavucontrol?
Well personally, I think it should be a pulse module, but there is no
real reason it cannot be a separate pulse client (I'd suspect it would
be a new program rather than pavucontrol if this was the case).
I was waiting to continue my work on the notification system until
Lennart had explained/developed a way to integrate better a module into
the glib main loop as the event handling system (the feedback bit) is
currently broken in my branch that deals with this.
So it'll be a little while before I can make progress, but it sounds
like I've been thinking along the same lines as yourself as the cases
and scenarios you mention above are identical to the ones that motivated
me to start work on this system.
Tribalogic Limited [http://www.tribalogic.net/]
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
More information about the pulseaudio-discuss