On 2011-05-20 10:36, Colin Guthrie wrote:
'Twas brillig, and David Henningsson at 20/05/11 07:23 did gyre and gimble:
On 2011-05-19 20:53, Tanu Kaskinen wrote:
On Tue, 2011-05-17 at 13:44 +0200, David Henningsson wrote:
Agree with the port property. About the port vs profile question, I
think we might think that backwards from a user's perspective.
Conceptually I'd say we select port first (manually or automatic;
doesn't matter for this reasoning), then we evaluate what profiles make
sense to try. If we're on headphones, only stereo profile makes sense,
if we're on line-out, we might want to consider surround profiles. At
least I would want it to work that way in the UI.
Could you elaborate on having profiles without ports? IIRC Pulseaudio
would fail in this case.
No, Pulseaudio doesn't fail in the scenario that I'm talking about - the
"no ports" situation is an optimization for the case when there would be
only one port to select from. If the profile (or more precisely the
mapping associated with that profile) has only one path in the mixer
configuration, then the sink or source will not export any ports at all.
The reasoning for that is probably that having a single port on a sink
would be redundant, because currently the only functionality ports offer
is that the user can change between them.
However, if the "available" property is added to ports, then exposing
even just one port on a sink will not be redundant.
Then keeping that port makes more sense IMHO, compared to adding an
"available" property to profiles.
I agree that keeping the single port makes sense - or perhaps even
synthesizing two ports (in an ideal world my laptop which does not have
separate alsa mixers for HP vs. Spk) would behave in pretty much exactly
the same way as a laptop that does. When the jack is detected, I would
want the port to change and thus any other code that stores volumes
paired to a device+port would magically work in my scenario as the port
would actually change (obviously with two synthesized ports, only one
could be "available" at a time).
I'm not sure what you are proposing with regards to selecting ports. Did
I understand correctly that the user should be presented with all ports
of all sinks and sources of a card in one big list?
Something in that direction. E g in gnome-volume-control, you would
still have an output and an input tab (but the hardware tab could be
removed). On the output tab you would have:
1) a list of all ports with available != no (assuming we don't optimise
ports away)
2) a list of profiles available for that port (stereo, 5.1, etc)
3) balance controls for that profile
4) a "test speakers" button (moved from hardware tab)
5) a checkbox "select this port automatically when it becomes available"
Does that make sense?
It's hard to visualise without a GUI mockup, but in principle I'm not
against something along these lines.
In actual fact how I had imagined it was something like this (and this
is a topic I'll be discussing at the Desktop Summit as my talk is on
exactly this topic - how to expose configuration to the user):
List of Sinks:
Internal Audio Analog Stereo
Speakers
Headphones
Internal Audio Digital Stereo
USB Speakers
Network Tunnel to Foobar
Bluetooth Headset
In this GUI, the profiles are effectively "hidden". For any sinks that
are not currently present, they are greyed out. For devices that are not
currently present but would be possible by changing a card profile, some
form of "activate" button or option is displayed. If there is only one
profile that would activate that sink, then the card is switched to that
profile and the list redrawn appropriately. If there are more than one
profiles that result in that sink, the question is asked of the user
"Which hardware configuration would you like to use?" and then the
subset of profiles are show for the user to pick.
This unifies the hardware and output tabs (and obviously this would be
similarly exposed for input devices too).
With regards to ports, I think it makes sense to list them underneath
the device. Obviously only one is active at a time, so this could be a
drop down rather than a deeper level list.
I guess the primary question for me would be:
Should we consider sink+port to be a unique key in device order
priority lists?
Yes.
e.g. if we did, then the above presentation (if we assume it were
priority list ordered) wouldn't make sense Instead we'd get:
List of Sinks:
Internal Audio Analog Stereo (Headphones)
USB Speakers
Internal Audio Analog Stereo (Speakers)
Internal Audio Digital Stereo
Network Tunnel to Foobar
Bluetooth Headset
I would even say port first, other things later, like this:
Headphones (Internal)
Speakers (USB)
Speakers (Internal)
SPDIF (Internal)
Foobar (Network)
Headset (Bluetooth)
...because "port" is what is the closest to the casual user. Note that
"Analog Stereo" is also skipped in the list above as that is part of the
profile, and "Audio" is skipped because it's implicit (we don't deal
with anything else).
One could even consider skipping the device when there is only one port
with that name:
Headphones
Speakers (USB)
Speakers (Internal)
SPDIF
Foobar
Headset
I like the simplicity, but maybe that's going too far?
This would mean that if I do not have the jack plugged in, but I do have
my USB speakers, then the sound would come out of the USB device, but
when I plug in a 3.5mm jack to my built in speaker, the audio would
switch to that.
The above does have some fairly significant advantages (the above setup
paints the use case quite clearly IMO). Of course if the priority lists
are not exposed under some DEs (i.e. Gnome) then auto management of the
lists is more problematic... i.e. if we move a stream to a new device,
if the prio lists are not exposed, this will typically result internally
in us moving that device to the top of the list. But if our lists are
internally using device+port, then should the auto-management also move
all entries of that device to the top (preserving their current order of
ports) or just the single device+port that is currently in use?I
suspect the former is more logical as this is likely how the GUI will be
presented (i.e. it will be "Move to Internal Audio Analog Stereo" rather
than "Move to Internal Audio Analog Stereo (Headphones)") but it does
mean the above priority list would be impossible to configure under such
internal auto-management. Such is the tradeoff perhaps?
The only problem with combining sink+port into one "pseudo device" for
display in GUIs is it kinda breaks the whole "show all sinks from a
profile and allow them to be activated" GUI approach.
And so I'd like the "show all profiles for a port+sink" GUI approach
instead, and thus "Move to Headphones (Internal)". And so in this port
centric approach, only moving the port+sink combination would make the
most sense.
None of these ideas are set in stone and I'm not really a GUI expert of
anything, so this can all be accommodated in the long run... this is
likely more of a brain dump on how this is all exposed to higher up the
stack :)
Neither am I, and if you recall the outcome of the UDS session, I should
reach out to Canonical's design team and ask them to do some user
expectation/testing stuff. I don't want us (as in the upstream) to have
to wait on the outcome of that, because I don't know exactly how or when
this will happen.
Anyway, keep up the good work :-)
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
