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>
