[pulseaudio-discuss] padevchooser improvements

Michael Gratton mike at vee.net
Wed Nov 26 16:35:09 PST 2008


Hey Colin,

On Wed, 2008-11-12 at 10:35 +0000, Colin Guthrie wrote:
> 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!

Well, they are pretty well hidden, then. :)

> I'd still suspect that tunnels are the way to go in this use case too to 
> be honest,

Which is fine, I'm not terribly interested the technical side of how it
is implemented, I would just like to make a better user experience.

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

I think you have an advantage here knowing that tunnels actually exist,
what they do and knowing how to move streams around on them, but I still
really don't think the current UI works in general.

I don't think many/any underlying changes to PA's protocol, or
implementation should/would be required at all, just some smarter UI.

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

Okay, I take that back - it's sticky across tracks and restarting
Rhythmbox, just not across the network disappearing.

> Again, I'm sure Lennart would appreciate any patches to the pavucontrol 
> program to make the interface more intuitive.

I know, this is where I should come in, but to be honest, pavucontrol is
total overkill for what I'm looking for - c.f. previous mail, but in
summary: a tray icon that appears only when network streams are
available, with a drop-down containing just host names that when
selected sets the default sink (and maybe migrates existing streams) to
something sane on that host.

If padevchooser really is going away I might just hack together up a
small app that does this, I really don't have the time to look into
fixing pavucontrol.

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

Actually, they are named in a terribly non-obvious, obfuscated way. For
example, I currently have the following sinks:

      * ALSA PCM on front:0 (AD198x Analog) via DMA
      * Simultaneous output to ALSA PCM on front:0 (AD198x Analog) via
        DMA
      * Simultaneous output to ALSA PCM on front:0 (AD198x Analog) via
        DMA on michael.gratton at localhost
      * ALSA PCM on front:0 (AD198x Analog) via DMA on
        michael.gratton at localhost

Two of these are tunnels to a different host. Which one should I choose?
That list above should instead look vaguely like this (maybe with the
explanatory text replaced with an appropriate icon and tooltip):

      * tremelay, this computer
      * clamps, local network

Why? Given that I have chosen to use simultaneous output, the
non-simultaneous streams should not be listed. The tunnels should at
least indicate the hostname they are connected to. No one really cares
about any of the following: If a sink allows simultaneous output or not,
if it uses ASLA, PCM, DMA, or what kind of audio card it is connected to
(unless they have more than one connected) - people who do care about
that sort of detail can use pactl.

This is also what the drop down list from the status icon of a
theoretical padevchooser replacement should look like.

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

That's really nifty, but where can the user set policy for defaults in
the case of sinks disappearing then multiple streams re-appearing? Can a
sink be given priority over another if another disappears or re-appears?

> I've started work (stalled for now) on a notification framework for 
> pulse.

It would be interesting to see how it shapes up, but I would suggest
that moving streams to networked hosts would be the exception rather
than the rule, so there needs to be some way of suppressing
notifications - my old workplace had almost 100 linux desktops...
individual notifications would be horrible in that case.

/Mike

-- 
⎊ Michael Gratton. "Mea navis aëricumbens anguillis abundat."
⎈ <http://web.vee.net/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20081127/e6840a8b/attachment.pgp>


More information about the pulseaudio-discuss mailing list