[pulseaudio-discuss] padevchooser improvements

[Colin Guthrie]

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
>> advantages.
> 
> 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,
> either.

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

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
load-module module-rescue-streams

### Make sure we always have a sink around, even if it is a null sink.
load-module module-always-sink



>> A lot of what you describe here should really be handled in pulseaudio
>> itself.
> 
> 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
> overridden.

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.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
   Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
   Mandriva Linux Contributor [http://www.mandriva.com/]
   PulseAudio Hacker [http://www.pulseaudio.org/]
   Trac Hacker [http://trac.edgewall.org/]