Re: [pulseaudio-discuss] Jack detection
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'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? -- 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
Re: [pulseaudio-discuss] Jack detection
'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
Re: [pulseaudio-discuss] Jack detection
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
Re: [pulseaudio-discuss] Jack detection (was: Re: [PATCHv3 0/4] Read and store UCM data as proplist)
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. 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? Pulseaudio should have an abstraction for jacks. Jack objects would be created by whatever alsa module is appropriate for that. Maybe module-alsa-card would be the best choice, or maybe not. There exists hardware where physical jacks are shared between multiple alsa cards. Really? Is that some embedded scenario? Yep. Simplifying a bit, one card handles the playback uses of the jack, and one card handles the capture uses of the jack. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Jack detection (was: Re: [PATCHv3 0/4] Read and store UCM data as proplist)
On 2011-05-12 09:37, Tanu Kaskinen wrote: On Wed, 2011-05-11 at 12:43 +0100, Colin Guthrie wrote: 'Twas brillig, and Jorge Eduardo Candelaria at 10/05/11 21:29 did gyre and gimble: This is the third version of the Pulseaudio and UCM integration. This set of patches cover adding ucm data to proplist, adding a ucm API to get and set data to proplist, and lets module-alsa-card scan ucm data when the card is probed. Another set of patches dealing with jack module detection will be sent separately. Thanks for this. I believe David will be helping review this stuff, but is currently at UDS. WRT the jack detection, I think we all agreed that it needs to be handled more internally in the alsa code rather than separated as a module. I'm not 100% sure of the finer details but I know David had ideas here too. We basically need to match up the jack stuff with the appropriate sink/source device on the system and then develop a way to automatically change sink/source ports accordingly (it may also require that we change the card profile too - e.g. change from a 5.1 profile to a stereo profile when plugging in stereo headphones). I'm not sure how to detect multiple jacks - e.g. if you plug in 3 jacks to do 5.1 output, should 5.1 be handled automatically? FWIW, I'll share some thoughts I've had about jack detection (I have not read the proposed code lately): Ports should have a property called available. (Some profiles don't have any ports, so profiles would also have to have the available status. Another possibility is to change this so that even single-mode profiles would have a port, and I think this would actually be a better idea than adding the available status to profiles.) The possible values would be yes, no and no clue. Without jack detection, the value would always be no clue, because currently we have no clue whether a port is actually connected to anything. 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. Whatever policy we want for automatically switching ports and profiles should be in a separate module. It would follow the port availability status and do something smart with that information. And that's what we're hoping Colin will write some time in the not too distant future :-) Pulseaudio should have an abstraction for jacks. Jack objects would be created by whatever alsa module is appropriate for that. Maybe module-alsa-card would be the best choice, or maybe not. There exists hardware where physical jacks are shared between multiple alsa cards. Really? Is that some embedded scenario? So maybe module-udev-detect would be a better place than module-alsa-card for creating the jacks, or maybe a new module is needed. The alsa modules would then also have to match the physical jacks to the ports, which may be tricky - some ports require multiple jacks to be connected, and on the other hand multiple ports can share one jack. The matching can probably be done for HDA by parsing the event name (you can see this name in evtest) but we might need manual options for people wanting to set up the match manually. Anyway, the status of the jacks associated with a port would determine the available status of the port. Something to keep in mind is also that one physical jack can have more states than connected and not connected. The 3.5 mm jack in N900, for example, can be used with headphones, headsets, microphones, or it can be connected to a TV. These different accessory types should trigger different ports to be activated. So, either the jack objects in Pulseaudio would need to have more than two possible states, or the physical jacks should be mapped to multiple abstract jacks for each accessory type. I'd probably go with the multiple abstract jacks with simple on/off status. Agreed, one jack object for headphone connection, another jack object for microphone. A headset would typically activate both. The TV might be a third jack object. -- 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
