[pulseaudio-discuss] Jack detection

Fri May 20 01:36:21 PDT 2011

'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?

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

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.

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 :)

Hope it's vaguely useful and understandable (it's often quite hard to
describe what you visualise quite clearly in your head!)

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]