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
