On Thu, 15.11.07 10:41, Esteban Salazar ([EMAIL PROTECTED]) 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=pavucontrolr1=62r2=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
