[pulseaudio-discuss] pulse gui

[Lennart Poettering]

On Thu, 15.11.07 10:41, Esteban Salazar (eagsalazar at gmail.com) wrote:

> So I watched the video.   I guess what I find confusing is this notion of
> "Moving" streams.  I think a lot could be resolved instead by getting rid of
> the notion of moving streams and instead conceptually have streams exist
> always and independent (similar to now) but instead of moving streams you
> just specify which outputs they are conneced to.

I am not sure if that's true. Having such a patchbay might make sense
for pro audio stuff. But for normal users the most common case is
output on all devices simultaneously, and alternatively output on only
one device at a time, I would say.

If people really want more complicated setups they are welcome to edit
the PA configuration files to add arbitrarily configured
"module-combine" sinks.

Hiding/reconfiguring the virtual "combine" sink would come either
at the cost of additional latency or at making the code of PA more
exceptionally more difficult. Why? because evening out the different
quartzes of the devices is done in a seperate thread -- this comes at
the cost of an additional context switch and some buffering. Which
makes it diserable to not do it if we only output on a single
device. However, switching between these modes constantly and without
interruptions in playback is very hard, makes the core of PA very
complex and the latencies very unreliable.

But yes, I agree to have this would be nice. However, I doubt that
there is a good real-life use case for this that would justify the
cost of doing things like this.

> So, if I want to direct a stream to my three outputs (o1,o2,o3), I can just
> specify in the gui by checking those three boxes.  This really simplifies
> things because some of the more confusing concepts in pulse just go away.
> For example, you don't need virtual devices anymore (you might keep them
> around as a convenient shorthand for saying hook up these a,b,c devices to
> this stream but you don't need them anymore and only advanced users would
> care about the shortcut).  

Uh? On one hand you say it is confusing and then you call it
convenience? 

The use case I have is that someone wants to switch playback from his
internal laptop speakers to his usb headset, and such like. If we'd
implement what you suggest then the user would first have to enable
output on the target device and then disable output on the internal
speakers. Two clicks instead of just one. Also, if we'd do what you
suggest then the user might end up with having a stream that is not
connected to any output. Something which is *really* confusing I would
say.

In short: I think that *moving* streams between devices is what the
user wants. Not *copying* them.

> Also the confusion with multicast streams and looping back to
> speakers goes away.  You just treat multicast output as another
> output device and if you also want audio to come out of your local
> speakers, you just also leave your local speakers checked.

Uh, that's not quite the same.

Also, multicast streams are very exotic things. The normal user
shouldn't think about them, and see them ever. And for those who like
to play with it it is fine to open paprefs and click on a few
checkboxes.

I see ne value in making multicast streams even more easy to
use. They are already ridiculuously easy to enable. It probably takes
more time to understand what "Multicasting" actually is then to enable
them.

> I think the current gui actually has a bug because you are using
> check boxes instead of radio boxes for moving streams but in the
> change I'm talking about, that would actually be what you want
> except that you could check multiple boxes at once.

Yes, this bug has been reported before. This will be fixed in the next
release of pavucontrol. Here's the commit:

http://svn.0pointer.de/viewvc/trunk/src/pavucontrol.cc?root=pavucontrol&r1=62&r2=67

> My idea in the image I send was just in recognition of that fact that many
> gui apps are associated with a single stream so it makes sense to also
> expose this exact dialog in the window menu so you can direct the output of
> that app direct from the app instead of having to open and extra pulse
> dialogs.

Yes, I acknowledge this part. And I plan to implement something like
this as mentioned. However, I will do it with *moving* streams, not
*copying* them.

> Having things associated with the window manager is also cool because just
> like remembering window locations and dimensions when a program is launched,
> the window manager (or whatever) could remember audio settings from previous
> launches so you wouldn't really have to ever set this stuff up except when
> you wanted to change it which for most streams you never would.  For
> example, once I specify that I want all my desktop sounds only to go to the
> local speakers, I'm never going to change that, same thing with directing my
> audio player outputs to my living room stereo.

PA already remembers the device and volume of all applications and
restores them when they connect the next time.

> Also, the concept of multicast streams is very confusing.  Right now if the
> gui for this stuff is confusing and I have only gotten network play to work
> by pure trial and error.  Most of that is simply not needed if you rearrange
> things like I suggesting except for playing someone else's stream locally.
> For that a person probably would need to go to a dedicated stream manager or
> something but that could be done from the existing stream/output/input
> dialogs or there could be a pulse audio "player" that does only that.  Then
> you don't need the stream/output/input tool at all.

As mentioned multicast streaming is nothing normal user would ever
want to touch. It's an exotic feature for an exotic purpose. If you
want to use it you are expected to understand what it means.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4