[alsa-devel] Separate input and output jacks for one UCM device?
Hi Liam and alsa-devel,
My understanding is that a UCM device can represent a thing that has both input and output (I don't particularly like that, but it's too late to complain). How likely do you think that there are or there will be some drivers that expose separate input and output jack kcontrols for a headset jack, to differentiate between headphones/headset/microphone? My understanding is that jack kcontrols store only booleans, so there's no way to distinguish between headphones and a headset with just one kcontrol.
The current UCM "spec" doesn't support specifying multiple kcontrols, since there's only one "JackControl" value. (Perhaps the "JackDev" value suffers from this problem too, but I don't know if jack input devices already support reporting the state separately for input and output.)
On Wed, 2015-03-18 at 21:41 +0200, Tanu Kaskinen wrote:
Hi Liam and alsa-devel,
I've added a few others on the CC that would be interested.
My understanding is that a UCM device can represent a thing that has both input and output (I don't particularly like that, but it's too late to complain).
Yes, but it can also represent simplex devices too e.g. "Headset-Speakers" and "Headset-Mic". There are not any hard rules here, but most examples are using duplex devices as historically UCM came from the phone ecosystem use cases.
How likely do you think that there are or there will be some drivers that expose separate input and output jack kcontrols for a headset jack, to differentiate between headphones/headset/microphone? My understanding is that jack kcontrols store only booleans, so there's no way to distinguish between headphones and a headset with just one kcontrol.
This sounds like we need to extend the jack kcontrol so that we can differentiate between Headphones and Headset unless the kcontrol naming was intended to differentiate and define the jack type ?
The current UCM "spec" doesn't support specifying multiple kcontrols, since there's only one "JackControl" value. (Perhaps the "JackDev" value suffers from this problem too, but I don't know if jack input devices already support reporting the state separately for input and output.)
I think in this case we could define simplex UCM devices and attach a JackControl value to each device.
Btw, I'm assuming it's better for pulseaudio to map the UCM devices as simplex unidirectional devices ?
Liam
At Thu, 19 Mar 2015 09:15:59 +0000, Liam Girdwood wrote:
On Wed, 2015-03-18 at 21:41 +0200, Tanu Kaskinen wrote:
Hi Liam and alsa-devel,
I've added a few others on the CC that would be interested.
My understanding is that a UCM device can represent a thing that has both input and output (I don't particularly like that, but it's too late to complain).
Yes, but it can also represent simplex devices too e.g. "Headset-Speakers" and "Headset-Mic". There are not any hard rules here, but most examples are using duplex devices as historically UCM came from the phone ecosystem use cases.
How likely do you think that there are or there will be some drivers that expose separate input and output jack kcontrols for a headset jack, to differentiate between headphones/headset/microphone? My understanding is that jack kcontrols store only booleans, so there's no way to distinguish between headphones and a headset with just one kcontrol.
This sounds like we need to extend the jack kcontrol so that we can differentiate between Headphones and Headset unless the kcontrol naming was intended to differentiate and define the jack type ?
Yeah, that's what we really need to face seriously now to. Keyon is working on merging input and kctl jacks, and this is the biggest problem that has to be sorted out.
As far as I understand correctly, so far ASoC drivers also report headset as boolean (the bits are multiple, but reports are either zero or N bits). So, we agreed on creating boolean "Headset" kctls.
One option is to provide multiple boolean kctls ("Headset Mic Jack"). Another option is to allow enum type for kctl jacks. Or, yet another alternative is to provide an enum ctl (e.g. "Headset Jack Type") in addition to a boolean kctl ("Headset Jack"). There can be other ways, too...
Takashi
On Thu, Mar 19, 2015 at 03:09:30PM +0100, Takashi Iwai wrote:
As far as I understand correctly, so far ASoC drivers also report headset as boolean (the bits are multiple, but reports are either zero or N bits). So, we agreed on creating boolean "Headset" kctls.
That's right - every input our output that might appear on the port is a separate boolean flag so we can represent any combination of them.
One option is to provide multiple boolean kctls ("Headset Mic Jack"). Another option is to allow enum type for kctl jacks. Or, yet another alternative is to provide an enum ctl (e.g. "Headset Jack Type") in addition to a boolean kctl ("Headset Jack"). There can be other ways, too...
I think any of those work; my guess is that the "Headset Jack Type" enum is the one that's going to be least disruptive to the ABI (in that it keeps the existing control untouched).
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Thursday, March 19, 2015 10:10 PM To: Liam Girdwood Cc: Tanu Kaskinen; alsa-devel@alsa-project.org; Arun Raghavan; Lu, Han; Mark Brown; Jie, Yang Subject: Re: Separate input and output jacks for one UCM device?
At Thu, 19 Mar 2015 09:15:59 +0000, Liam Girdwood wrote:
On Wed, 2015-03-18 at 21:41 +0200, Tanu Kaskinen wrote:
Hi Liam and alsa-devel,
I've added a few others on the CC that would be interested.
My understanding is that a UCM device can represent a thing that has both input and output (I don't particularly like that, but it's too late to complain).
Yes, but it can also represent simplex devices too e.g. "Headset-Speakers" and "Headset-Mic". There are not any hard rules here, but most examples are using duplex devices as historically UCM came from the phone ecosystem use cases.
How likely do you think that there are or there will be some drivers that expose separate input and output jack kcontrols for a headset jack, to differentiate between headphones/headset/microphone? My understanding is that jack kcontrols store only booleans, so there's no way to distinguish between headphones and a headset with just one
kcontrol.
This sounds like we need to extend the jack kcontrol so that we can differentiate between Headphones and Headset unless the kcontrol naming was intended to differentiate and define the jack type ?
Yeah, that's what we really need to face seriously now to. Keyon is working on merging input and kctl jacks, and this is the biggest problem that has to be sorted out.
As far as I understand correctly, so far ASoC drivers also report headset as boolean (the bits are multiple, but reports are either zero or N bits). So, we agreed on creating boolean "Headset" kctls.
One option is to provide multiple boolean kctls ("Headset Mic Jack").
[Keyon] how about using "Headset Jack Mic" and "Headset Jack Speakers"? Then we can understand of that both these two kctls are belong to the Headset Jack.
Another option is to allow enum type for kctl jacks. Or, yet another alternative is to provide an enum ctl (e.g. "Headset Jack Type") in addition to a boolean kctl ("Headset Jack"). There can be other ways, too...
Takashi
At Thu, 19 Mar 2015 14:22:18 +0000, Jie, Yang wrote:
From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Thursday, March 19, 2015 10:10 PM To: Liam Girdwood Cc: Tanu Kaskinen; alsa-devel@alsa-project.org; Arun Raghavan; Lu, Han; Mark Brown; Jie, Yang Subject: Re: Separate input and output jacks for one UCM device?
At Thu, 19 Mar 2015 09:15:59 +0000, Liam Girdwood wrote:
On Wed, 2015-03-18 at 21:41 +0200, Tanu Kaskinen wrote:
Hi Liam and alsa-devel,
I've added a few others on the CC that would be interested.
My understanding is that a UCM device can represent a thing that has both input and output (I don't particularly like that, but it's too late to complain).
Yes, but it can also represent simplex devices too e.g. "Headset-Speakers" and "Headset-Mic". There are not any hard rules here, but most examples are using duplex devices as historically UCM came from the phone ecosystem use cases.
How likely do you think that there are or there will be some drivers that expose separate input and output jack kcontrols for a headset jack, to differentiate between headphones/headset/microphone? My understanding is that jack kcontrols store only booleans, so there's no way to distinguish between headphones and a headset with just one
kcontrol.
This sounds like we need to extend the jack kcontrol so that we can differentiate between Headphones and Headset unless the kcontrol naming was intended to differentiate and define the jack type ?
Yeah, that's what we really need to face seriously now to. Keyon is working on merging input and kctl jacks, and this is the biggest problem that has to be sorted out.
As far as I understand correctly, so far ASoC drivers also report headset as boolean (the bits are multiple, but reports are either zero or N bits). So, we agreed on creating boolean "Headset" kctls.
One option is to provide multiple boolean kctls ("Headset Mic Jack").
[Keyon] how about using "Headset Jack Mic" and "Headset Jack Speakers"? Then we can understand of that both these two kctls are belong to the Headset Jack.
This would be OK, too. BTW, an obvious drawback of splitting boolean kctls is that you'll receive multiple events. For example, when triggering a headset, both headset mic and headset speaker ctls will get an event.
Takashi
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Thursday, March 19, 2015 10:10 PM To: Liam Girdwood Cc: Tanu Kaskinen; alsa-devel@alsa-project.org; Arun Raghavan; Lu, Han; Mark Brown; Jie, Yang Subject: Re: Separate input and output jacks for one UCM device?
At Thu, 19 Mar 2015 09:15:59 +0000, Liam Girdwood wrote:
On Wed, 2015-03-18 at 21:41 +0200, Tanu Kaskinen wrote:
Hi Liam and alsa-devel,
I've added a few others on the CC that would be interested.
My understanding is that a UCM device can represent a thing that has both input and output (I don't particularly like that, but it's too late to complain).
Yes, but it can also represent simplex devices too e.g. "Headset-Speakers" and "Headset-Mic". There are not any hard rules here, but most examples are using duplex devices as historically UCM came from the phone ecosystem use cases.
How likely do you think that there are or there will be some drivers that expose separate input and output jack kcontrols for a headset jack, to differentiate between headphones/headset/microphone? My understanding is that jack kcontrols store only booleans, so there's no way to distinguish between headphones and a headset with just one
kcontrol.
This sounds like we need to extend the jack kcontrol so that we can differentiate between Headphones and Headset unless the kcontrol naming was intended to differentiate and define the jack type ?
Yeah, that's what we really need to face seriously now to. Keyon is working on merging input and kctl jacks, and this is the biggest problem that has to be sorted out.
As far as I understand correctly, so far ASoC drivers also report headset as boolean (the bits are multiple, but reports are either zero or N bits). So, we agreed on creating boolean "Headset" kctls.
One option is to provide multiple boolean kctls ("Headset Mic Jack"). Another option is to allow enum type for kctl jacks. Or, yet another alternative is to provide an enum ctl (e.g. "Headset Jack Type") in addition to a boolean kctl ("Headset Jack"). There can be other ways, too...
[Keyon] I have another concern, should app(e.g. pulseaudio) also need be able to handle different index with same "Headset Jack" kctl name? or we should register them as "Headset Jack N Mic" (n=0, 1, 2, ...)?
Takashi
At Thu, 19 Mar 2015 14:31:58 +0000, Jie, Yang wrote:
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Thursday, March 19, 2015 10:10 PM To: Liam Girdwood Cc: Tanu Kaskinen; alsa-devel@alsa-project.org; Arun Raghavan; Lu, Han; Mark Brown; Jie, Yang Subject: Re: Separate input and output jacks for one UCM device?
At Thu, 19 Mar 2015 09:15:59 +0000, Liam Girdwood wrote:
On Wed, 2015-03-18 at 21:41 +0200, Tanu Kaskinen wrote:
Hi Liam and alsa-devel,
I've added a few others on the CC that would be interested.
My understanding is that a UCM device can represent a thing that has both input and output (I don't particularly like that, but it's too late to complain).
Yes, but it can also represent simplex devices too e.g. "Headset-Speakers" and "Headset-Mic". There are not any hard rules here, but most examples are using duplex devices as historically UCM came from the phone ecosystem use cases.
How likely do you think that there are or there will be some drivers that expose separate input and output jack kcontrols for a headset jack, to differentiate between headphones/headset/microphone? My understanding is that jack kcontrols store only booleans, so there's no way to distinguish between headphones and a headset with just one
kcontrol.
This sounds like we need to extend the jack kcontrol so that we can differentiate between Headphones and Headset unless the kcontrol naming was intended to differentiate and define the jack type ?
Yeah, that's what we really need to face seriously now to. Keyon is working on merging input and kctl jacks, and this is the biggest problem that has to be sorted out.
As far as I understand correctly, so far ASoC drivers also report headset as boolean (the bits are multiple, but reports are either zero or N bits). So, we agreed on creating boolean "Headset" kctls.
One option is to provide multiple boolean kctls ("Headset Mic Jack"). Another option is to allow enum type for kctl jacks. Or, yet another alternative is to provide an enum ctl (e.g. "Headset Jack Type") in addition to a boolean kctl ("Headset Jack"). There can be other ways, too...
[Keyon] I have another concern, should app(e.g. pulseaudio) also need be able to handle different index with same "Headset Jack" kctl name? or we should register them as "Headset Jack N Mic" (n=0, 1, 2, ...)?
The uniqueness of item name is also needed for input jack. There is no check as of now, and input drivers allow multiple items with the very same name string, but user-space can't distinguish them.
Takashi
On Thu, Mar 19, 2015 at 03:37:12PM +0100, Takashi Iwai wrote:
The uniqueness of item name is also needed for input jack. There is no check as of now, and input drivers allow multiple items with the very same name string, but user-space can't distinguish them.
The theory is that this is handled by the fact that the userspace ABI includes a reference to the struct device and therefore a chain showing where the thing is attached; anything registering two different jacks with the same name attached to the same device probably qualifies as broken.
At Thu, 19 Mar 2015 14:42:40 +0000, Mark Brown wrote:
On Thu, Mar 19, 2015 at 03:37:12PM +0100, Takashi Iwai wrote:
The uniqueness of item name is also needed for input jack. There is no check as of now, and input drivers allow multiple items with the very same name string, but user-space can't distinguish them.
The theory is that this is handled by the fact that the userspace ABI includes a reference to the struct device and therefore a chain showing where the thing is attached; anything registering two different jacks with the same name attached to the same device probably qualifies as broken.
So this implicitly assumes the name uniqueness. For HD-audio, this was a problem because we need to generate jack names dynamically; for example, there are laptops with two headphones, and we assigned indices in such a case.
Takashi
On Thu, Mar 19, 2015 at 03:51:06PM +0100, Takashi Iwai wrote:
Mark Brown wrote:
The theory is that this is handled by the fact that the userspace ABI includes a reference to the struct device and therefore a chain showing where the thing is attached; anything registering two different jacks with the same name attached to the same device probably qualifies as broken.
So this implicitly assumes the name uniqueness. For HD-audio, this was a problem because we need to generate jack names dynamically; for example, there are laptops with two headphones, and we assigned indices in such a case.
That's on the same card, though? I'd expect a device creating two input jacks to do the same (putting the number in the name, or some other identifer like "front" and "back").
At Thu, 19 Mar 2015 15:18:51 +0000, Mark Brown wrote:
On Thu, Mar 19, 2015 at 03:51:06PM +0100, Takashi Iwai wrote:
Mark Brown wrote:
The theory is that this is handled by the fact that the userspace ABI includes a reference to the struct device and therefore a chain showing where the thing is attached; anything registering two different jacks with the same name attached to the same device probably qualifies as broken.
So this implicitly assumes the name uniqueness. For HD-audio, this was a problem because we need to generate jack names dynamically; for example, there are laptops with two headphones, and we assigned indices in such a case.
That's on the same card, though?
Yeah, on the same laptop, even both on the front. The designer must have smoked, or just looked for a partner sitting at next to listen to music together :)
I'd expect a device creating two input jacks to do the same (putting the number in the name, or some other identifer like "front" and "back").
Yes, stringifying the index number would work.
Takashi
On Thu, Mar 19, 2015 at 04:28:40PM +0100, Takashi Iwai wrote:
Mark Brown wrote:
That's on the same card, though?
Yeah, on the same laptop, even both on the front. The designer must have smoked, or just looked for a partner sitting at next to listen to music together :)
Our hardware engineering colleagues are innovative and creative people who keep us in work! :P
The theory is that this is handled by the fact that the userspace
ABI
includes a reference to the struct device and therefore a chain
showing
where the thing is attached; anything registering two different
jacks
with the same name attached to the same device probably qualifies as broken.
So this implicitly assumes the name uniqueness. For HD-audio, this was a problem because we need to generate jack names dynamically; for example, there are laptops with two headphones, and we assigned indices in such a case.
That's on the same card, though?
Yeah, on the same laptop, even both on the front. The designer must have smoked, or just looked for a partner sitting at next to listen to music together :)
http://en.community.dell.com/support-forums/laptop/f/3517/t/19440542
One of the headphone jack is actually headphone/SPDIF combo jack
and the two headphone jacks and mic jack can support surround 5.1
Reviving this thread...
On Thu, 2015-03-19 at 09:15 +0000, Liam Girdwood wrote:
On Wed, 2015-03-18 at 21:41 +0200, Tanu Kaskinen wrote:
Hi Liam and alsa-devel,
I've added a few others on the CC that would be interested.
My understanding is that a UCM device can represent a thing that has both input and output (I don't particularly like that, but it's too late to complain).
Yes, but it can also represent simplex devices too e.g. "Headset-Speakers" and "Headset-Mic". There are not any hard rules here, but most examples are using duplex devices as historically UCM came from the phone ecosystem use cases.
How likely do you think that there are or there will be some drivers that expose separate input and output jack kcontrols for a headset jack, to differentiate between headphones/headset/microphone? My understanding is that jack kcontrols store only booleans, so there's no way to distinguish between headphones and a headset with just one kcontrol.
This sounds like we need to extend the jack kcontrol so that we can differentiate between Headphones and Headset unless the kcontrol naming was intended to differentiate and define the jack type ?
I guess it's now clear that all jack kcontrols will be booleans, and headset jacks will require two jack kcontrols.
The current UCM "spec" doesn't support specifying multiple kcontrols, since there's only one "JackControl" value. (Perhaps the "JackDev" value suffers from this problem too, but I don't know if jack input devices already support reporting the state separately for input and output.)
I think in this case we could define simplex UCM devices and attach a JackControl value to each device.
So is your preference that UCM configuration authors are forced to define simplex devices to deal with headset jacks, rather than using duplex devices and defining "PlaybackJackControl" and "CaptureJackControl" separately? (I don't personally mind either way.)
On Tue, 2015-03-31 at 19:49 +0300, Tanu Kaskinen wrote:
Reviving this thread...
On Thu, 2015-03-19 at 09:15 +0000, Liam Girdwood wrote:
On Wed, 2015-03-18 at 21:41 +0200, Tanu Kaskinen wrote:
Hi Liam and alsa-devel,
I've added a few others on the CC that would be interested.
My understanding is that a UCM device can represent a thing that has both input and output (I don't particularly like that, but it's too late to complain).
Yes, but it can also represent simplex devices too e.g. "Headset-Speakers" and "Headset-Mic". There are not any hard rules here, but most examples are using duplex devices as historically UCM came from the phone ecosystem use cases.
How likely do you think that there are or there will be some drivers that expose separate input and output jack kcontrols for a headset jack, to differentiate between headphones/headset/microphone? My understanding is that jack kcontrols store only booleans, so there's no way to distinguish between headphones and a headset with just one kcontrol.
This sounds like we need to extend the jack kcontrol so that we can differentiate between Headphones and Headset unless the kcontrol naming was intended to differentiate and define the jack type ?
I guess it's now clear that all jack kcontrols will be booleans, and headset jacks will require two jack kcontrols.
The current UCM "spec" doesn't support specifying multiple kcontrols, since there's only one "JackControl" value. (Perhaps the "JackDev" value suffers from this problem too, but I don't know if jack input devices already support reporting the state separately for input and output.)
I think in this case we could define simplex UCM devices and attach a JackControl value to each device.
So is your preference that UCM configuration authors are forced to define simplex devices to deal with headset jacks, rather than using duplex devices and defining "PlaybackJackControl" and "CaptureJackControl" separately? (I don't personally mind either way.)
I don't really mind either, but what's easier for audio servers like pulseaudio that will be the main UCM clients ? I guess that pulseaudio, CRAS, and other audio servers probably deal with simplex PCM streams internally so mapping to simplex jacks/devices might be better ?
Liam
On Wed, 2015-04-01 at 13:27 +0100, Liam Girdwood wrote:
On Tue, 2015-03-31 at 19:49 +0300, Tanu Kaskinen wrote:
So is your preference that UCM configuration authors are forced to define simplex devices to deal with headset jacks, rather than using duplex devices and defining "PlaybackJackControl" and "CaptureJackControl" separately? (I don't personally mind either way.)
I don't really mind either, but what's easier for audio servers like pulseaudio that will be the main UCM clients ? I guess that pulseaudio, CRAS, and other audio servers probably deal with simplex PCM streams internally so mapping to simplex jacks/devices might be better ?
Yes, the native device representation in PulseAudio uses the simplex model. However, the code for handling duplex UCM devices already exists, so it shouldn't take a big effort to support duplex devices with separate "PlaybackJackControl" and "CaptureJackControl" values.
I've added a few others on the CC that would be interested.
My understanding is that a UCM device can represent a thing that has both input and output (I don't particularly like that, but it's too
late
to complain).
Yes, but it can also represent simplex devices too e.g. "Headset-Speakers" and "Headset-Mic". There are not any hard rules
here,
but most examples are using duplex devices as historically UCM came
from
the phone ecosystem use cases.
On some mobile phones which have FM radio , how do UCM handle FM radio since it need to use the headphone as antenna ?
How likely do you think that there are or there will be some drivers that expose separate input and output jack kcontrols
for a
headset jack, to differentiate between
headphones/headset/microphone? My
understanding is that jack kcontrols store only booleans, so
there's no
way to distinguish between headphones and a headset with just one
kcontrol.
This sounds like we need to extend the jack kcontrol so that we can differentiate between Headphones and Headset unless the kcontrol
naming
was intended to differentiate and define the jack type ?
I guess it's now clear that all jack kcontrols will be booleans, and headset jacks will require two jack kcontrols.
The current UCM "spec" doesn't support specifying multiple
kcontrols,
since there's only one "JackControl" value. (Perhaps the "JackDev"
value
suffers from this problem too, but I don't know if jack input
devices
already support reporting the state separately for input and
output.)
I think in this case we could define simplex UCM devices and attach a JackControl value to each device.
So is your preference that UCM configuration authors are forced to define simplex devices to deal with headset jacks, rather than using duplex devices and defining "PlaybackJackControl" and "CaptureJackControl" separately? (I don't personally mind either way.)
I don't really mind either, but what's easier for audio servers like pulseaudio that will be the main UCM clients ? I guess that pulseaudio, CRAS, and other audio servers probably deal with simplex PCM streams internally so mapping to simplex jacks/devices might be better ?
Liam
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On Thu, 2015-04-02 at 07:24 +0800, Raymond Yau wrote:
I've added a few others on the CC that would be interested.
My understanding is that a UCM device can represent a thing
that has
both input and output (I don't particularly like that, but
it's too late
to complain).
Yes, but it can also represent simplex devices too e.g. "Headset-Speakers" and "Headset-Mic". There are not any hard
rules here,
but most examples are using duplex devices as historically UCM
came from
the phone ecosystem use cases.
On some mobile phones which have FM radio , how do UCM handle FM radio since it need to use the headphone as antenna ?
This use case is just treated like any other where we have to set the proper kcontrols and devices in the UCM config. This would include the headphone if required for audio playback or antenna.
Liam
On Wed, Apr 1, 2015 at 5:27 AM, Liam Girdwood liam.r.girdwood@linux.intel.com wrote:
On Tue, 2015-03-31 at 19:49 +0300, Tanu Kaskinen wrote:
Reviving this thread...
On Thu, 2015-03-19 at 09:15 +0000, Liam Girdwood wrote:
On Wed, 2015-03-18 at 21:41 +0200, Tanu Kaskinen wrote:
Hi Liam and alsa-devel,
I've added a few others on the CC that would be interested.
My understanding is that a UCM device can represent a thing that has both input and output (I don't particularly like that, but it's too late to complain).
Yes, but it can also represent simplex devices too e.g. "Headset-Speakers" and "Headset-Mic". There are not any hard rules here, but most examples are using duplex devices as historically UCM came from the phone ecosystem use cases.
How likely do you think that there are or there will be some drivers that expose separate input and output jack kcontrols for a headset jack, to differentiate between headphones/headset/microphone? My understanding is that jack kcontrols store only booleans, so there's no way to distinguish between headphones and a headset with just one kcontrol.
This sounds like we need to extend the jack kcontrol so that we can differentiate between Headphones and Headset unless the kcontrol naming was intended to differentiate and define the jack type ?
I guess it's now clear that all jack kcontrols will be booleans, and headset jacks will require two jack kcontrols.
The current UCM "spec" doesn't support specifying multiple kcontrols, since there's only one "JackControl" value. (Perhaps the "JackDev" value suffers from this problem too, but I don't know if jack input devices already support reporting the state separately for input and output.)
I think in this case we could define simplex UCM devices and attach a JackControl value to each device.
So is your preference that UCM configuration authors are forced to define simplex devices to deal with headset jacks, rather than using duplex devices and defining "PlaybackJackControl" and "CaptureJackControl" separately? (I don't personally mind either way.)
I don't really mind either, but what's easier for audio servers like pulseaudio that will be the main UCM clients ? I guess that pulseaudio, CRAS, and other audio servers probably deal with simplex PCM streams internally so mapping to simplex jacks/devices might be better ?
There is an advantage to having a separate device for the headphone and mic even if they are connected to the same jack. The user can enable one and not the other, most commonly to use the headphones but record from the built-in mic, ignoring the headset mic. Because of this we require all ChromeOS devices to support separate reporting and selection of headphone/mic on the headset jack. There is always one UCM device and one user-visible i/o node per jack.
Liam
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
I've added a few others on the CC that would be interested.
My understanding is that a UCM device can represent a thing that
has
both input and output (I don't particularly like that, but it's
too late
to complain).
Yes, but it can also represent simplex devices too e.g. "Headset-Speakers" and "Headset-Mic". There are not any hard rules
here,
but most examples are using duplex devices as historically UCM came
from
the phone ecosystem use cases.
How likely do you think that there are or there will be some drivers that expose separate input and output jack kcontrols
for a
headset jack, to differentiate between
headphones/headset/microphone? My
understanding is that jack kcontrols store only booleans, so
there's no
way to distinguish between headphones and a headset with just one
kcontrol.
This sounds like we need to extend the jack kcontrol so that we can differentiate between Headphones and Headset unless the kcontrol
naming
was intended to differentiate and define the jack type ?
I guess it's now clear that all jack kcontrols will be booleans, and headset jacks will require two jack kcontrols.
The current UCM "spec" doesn't support specifying multiple
kcontrols,
since there's only one "JackControl" value. (Perhaps the "JackDev"
value
suffers from this problem too, but I don't know if jack input
devices
already support reporting the state separately for input and
output.)
I think in this case we could define simplex UCM devices and attach a JackControl value to each device.
So is your preference that UCM configuration authors are forced to define simplex devices to deal with headset jacks, rather than using duplex devices and defining "PlaybackJackControl" and "CaptureJackControl" separately? (I don't personally mind either way.)
I don't really mind either, but what's easier for audio servers like pulseaudio that will be the main UCM clients ? I guess that pulseaudio, CRAS, and other audio servers probably deal with simplex PCM streams internally so mapping to simplex jacks/devices might be better ?
There is an advantage to having a separate device for the headphone and
mic
even if they are connected to the same jack. The user can enable one and
not
the other, most commonly to use the headphones but record from the
built-in mic,
ignoring the headset mic. Because of this we require all ChromeOS
devices to
support separate reporting and selection of headphone/mic on the headset
jack.
There is always one UCM device and one user-visible i/o node per jack.
How do these kind of jack handle by UCM ?
http://www.dell.com/support/home/us/en/19/product-support/product/inspiron-1...
6 Headset port Connect a headphone, a microphone, or a headphone and microphone combo (headset).
https://launchpadlibrarian.net/193669943/AlsaInfo.txt
Seem there are three pin complexes for this combo jack
Node 0x0b [Audio Mixer] wcaps 0x20010b: Stereo Amp-In Control: name="Headset Mic Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=1, ofs=0 Control: name="Headset Mic Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=1, ofs=0 Control: name="Headphone Mic Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=2, ofs=0 Control: name="Headphone Mic Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=2, ofs=0 Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1 Amp-In vals: [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] Connection: 5 0x18 0x19 0x1a 0x1b 0x1d
Node 0x12 [Pin Complex] wcaps 0x40040b: Stereo Amp-In Control: name="Internal Mic Boost Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Internal Mic Phantom Jack", index=0, device=0 Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x2f, mute=0 Amp-In vals: [0x03 0x03] Pincap 0x00000020: IN Pin Default 0x90a60130: [Fixed] Mic at Int N/A Conn = Digital, Color = Unknown DefAssociation = 0x3, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x20: IN Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0
Node 0x14 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Control: name="Speaker Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Control: name="Speaker Phantom Jack", index=0, device=0 Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x00010014: OUT EAPD Detect EAPD 0x2: EAPD Pin Default 0x90170110: [Fixed] Speaker at Int N/A Conn = Analog, Color = Unknown DefAssociation = 0x1, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT Unsolicited: tag=00, enabled=0 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 1 0x0c
Node 0x19 [Pin Complex] wcaps 0x40048b: Stereo Amp-In Control: name="Headset Mic Boost Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Headset Mic Phantom Jack", index=0, device=0 Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x2f, mute=0 Amp-In vals: [0x03 0x03] Pincap 0x00003724: IN Detect Vref caps: HIZ 50 GRD 80 100 Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x24: IN VREF_80 Unsolicited: tag=00, enabled=0 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0
Node 0x21 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Control: name="Headphone Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Control: name="Headphone Mic Jack", index=0, device=0 Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x0001001c: OUT HP EAPD Detect EAPD 0x2: EAPD Pin Default 0x0321101f: [Jack] HP Out at Ext Left Conn = 1/8, Color = Black DefAssociation = 0x1, Sequence = 0xf Pin-ctls: 0xc0: OUT HP Unsolicited: tag=01, enabled=1 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 2 0x0c 0x0d*
sys/class/sound/hwC0D0/init_verbs:
/sys/class/sound/hwC1D0/init_pin_configs: 0x12 0x90a60130 0x14 0x90170110 0x17 0x40020008 0x18 0x411111f0 0x19 0x411111f0 0x1a 0x411111f0 0x1b 0x411111f0 0x1d 0x40e00001 0x1e 0x411111f0 0x21 0x0321101f
/sys/class/sound/hwC1D0/driver_pin_configs: 0x19 0x01a1913c 0x1a 0x01a1913d
On Sat, 2015-04-04 at 13:39 +0800, Raymond Yau wrote:
I've added a few others on the CC that would be interested.
My understanding is that a UCM device can represent a thing
that has
both input and output (I don't particularly like that, but
it's too late
to complain).
Yes, but it can also represent simplex devices too e.g. "Headset-Speakers" and "Headset-Mic". There are not any hard
rules here,
but most examples are using duplex devices as historically UCM
came from
the phone ecosystem use cases.
How likely do you think that there are or there will be some drivers that expose separate input and output jack
kcontrols for a
headset jack, to differentiate between
headphones/headset/microphone? My
understanding is that jack kcontrols store only booleans, so
there's no
way to distinguish between headphones and a headset with just
one kcontrol.
This sounds like we need to extend the jack kcontrol so that we
can
differentiate between Headphones and Headset unless the
kcontrol naming
was intended to differentiate and define the jack type ?
I guess it's now clear that all jack kcontrols will be booleans,
and
headset jacks will require two jack kcontrols.
The current UCM "spec" doesn't support specifying multiple
kcontrols,
since there's only one "JackControl" value. (Perhaps the
"JackDev" value
suffers from this problem too, but I don't know if jack input
devices
already support reporting the state separately for input and
output.)
I think in this case we could define simplex UCM devices and
attach a
JackControl value to each device.
So is your preference that UCM configuration authors are forced
to
define simplex devices to deal with headset jacks, rather than
using
duplex devices and defining "PlaybackJackControl" and "CaptureJackControl" separately? (I don't personally mind either
way.)
I don't really mind either, but what's easier for audio servers
like
pulseaudio that will be the main UCM clients ? I guess that
pulseaudio,
CRAS, and other audio servers probably deal with simplex PCM
streams
internally so mapping to simplex jacks/devices might be better ?
There is an advantage to having a separate device for the headphone
and mic
even if they are connected to the same jack. The user can enable
one and not
the other, most commonly to use the headphones but record from the
built-in mic,
ignoring the headset mic. Because of this we require all ChromeOS
devices to
support separate reporting and selection of headphone/mic on the
headset jack.
There is always one UCM device and one user-visible i/o node per
jack.
How do these kind of jack handle by UCM ?
http://www.dell.com/support/home/us/en/19/product-support/product/inspiron-1...
6 Headset port Connect a headphone, a microphone, or a headphone and microphone combo (headset).
UCM is not really needed for this device as Pulseaudio handles the standardised HDA jacks and routing (there is nothing stopping a UCM config being defined though). So for each input/output endpoint above you would list it's jack kcontrol in the endpoint device section. e.g. sound server reads jack input and type, checks UCM config and matches the device before setting routing according to UCM device.
UCM is mainly needed for non HDA devices that have different jack pins, volume controls and routing controls. Sound servers have no way of guessing the correct mixers and volume controls to use for non HDA devices as they are all very different HW.
Liam
How do these kind of jack handle by UCM ?
http://www.dell.com/support/home/us/en/19/product-support/product/inspiron-1...
6 Headset port Connect a headphone, a microphone, or a headphone and microphone combo (headset).
UCM is not really needed for this device as Pulseaudio handles the standardised HDA jacks and routing (there is nothing stopping a UCM config being defined though). So for each input/output endpoint above you would list it's jack kcontrol in the endpoint device section. e.g. sound server reads jack input and type, checks UCM config and matches the device before setting routing according to UCM device.
#ifdef CONFIG_SND_HDA_INPUT_JACK if (!phantom_jack) { jack->type = get_input_jack_type(codec, nid); err = snd_jack_new(codec->card, name, jack->type, &jack->jack); if (err < 0) return err; jack->jack->private_data = jack; jack->jack->private_free = hda_free_jack_priv; snd_jack_report(jack->jack, state ? jack->type : 0); } #endif
Current implementation only create input jack when CONFIG_SND_HDA_INPUT_JACK is defined but those input jacks are always created by the proposed change
Node 0x19 [Pin Complex] wcaps 0x40048b: Stereo Amp-In Control: name="Headset Mic Boost Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Headset Mic Phantom Jack", index=0, device=0 Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x2f, mute=0 Amp-In vals: [0x03 0x03] Pincap 0x00003724: IN Detect Vref caps: HIZ 50 GRD 80 100 Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x24: IN VREF_80 Unsolicited: tag=00, enabled=0 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Node 0x1a [Pin Complex] wcaps 0x40048b: Stereo Amp-In Control: name="Headphone Mic Boost Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x2f, mute=0 Amp-In vals: [0x00 0x00] Pincap 0x00003724: IN Detect Vref caps: HIZ 50 GRD 80 100 Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x20: IN VREF_HIZ Unsolicited: tag=00, enabled=0 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0
Node 0x21 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Control: name="Headphone Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Control: name="Headphone Mic Jack", index=0, device=0 Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x0001001c: OUT HP EAPD Detect EAPD 0x2: EAPD Pin Default 0x0321101f: [Jack] HP Out at Ext Left Conn = 1/8, Color = Black DefAssociation = 0x1, Sequence = 0xf Pin-ctls: 0xc0: OUT HP Unsolicited: tag=01, enabled=1 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 2 0x0c 0x0d*
This mean that those application which want to use kctl must ask the user to select the type of the jack whenever the user plugged the jack if the hatdware cannot distinguish headset, headphone or mic jack
What will happen when the user already plugged the jack before boot or restart pulseaudio server ?
http://bazaar.launchpad.net/~unity-settings-daemon-team/unity-settings-daemo...
In PulseAudio ports will show up with the following names: Headphones - analog-output-headphones Headset mic - analog-input-microphone-headset Jack in mic-in mode - analog-input-microphone
However, since regular mics also show up as analog-input-microphone, we need to check for certain controls on alsa mixer level too, to know if we deal with a separate mic jack, or a multi-function jack with a mic-in mode (also called "headphone mic"). We check for the following names:
Headphone Mic Jack - indicates headphone and mic-in mode share the same jack, i e, not two separate jacks. Hardware cannot distinguish between a headphone and a mic. Headset Mic Phantom Jack - indicates headset jack where hardware can not distinguish between headphones and headsets Headset Mic Jack - indicates headset jack where hardware can distinguish between headphones and headsets. There is no use popping up a dialog in this case, unless we already need to do this for the mic-in mode.
UCM is mainly needed for non HDA devices that have different jack pins, volume controls and routing controls. Sound servers have no way of guessing the correct mixers and volume controls to use for non HDA devices as they are all very different HW.
Do this mean that for those notebook which have three physical jacks : headset, headphone and mic jack should create headset jack headset mic jack, headphone jack and mic jack kctls ?
http://www.dell.com/support/home/us/en/19/product-support/product/alienware-...
17. Headphones and microphone combo port 18. Headphones/Speakers port 19. Microphone port
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1302090
https://launchpadlibrarian.net/171704958/alsa-info.txt.ReoE61oqo9
Node 0x15 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Control: name="Headphone Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Control: name="Headphone Front Jack", index=0, device=0 Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x0001001c: OUT HP EAPD Detect EAPD 0x2: EAPD Pin Default 0x0321101f: [Jack] HP Out at Ext Left Conn = 1/8, Color = Black DefAssociation = 0x1, Sequence = 0xf Pin-ctls: 0xc0: OUT HP Unsolicited: tag=01, enabled=1 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 3 0x0c* 0x0d 0x0e Node 0x16 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Control: name="Headphone Playback Switch", index=1, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Control: name="Headphone Surround Jack", index=0, device=0 Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x0000001c: OUT HP Detect Pin Default 0x03211020: [Jack] HP Out at Ext Left Conn = 1/8, Color = Black DefAssociation = 0x2, Sequence = 0x0 Pin-ctls: 0xc0: OUT HP Unsolicited: tag=02, enabled=1 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 3 0x0c 0x0d* 0x0e
Node 0x19 [Pin Complex] wcaps 0x40058f: Stereo Amp-In Amp-Out Control: name="Mic Boost Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Mic Jack", index=0, device=0 Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x0000373c: IN OUT HP Detect Vref caps: HIZ 50 GRD 80 100 Pin Default 0x03a11030: [Jack] Mic at Ext Left Conn = 1/8, Color = Black DefAssociation = 0x3, Sequence = 0x0 Pin-ctls: 0x24: IN VREF_80 Unsolicited: tag=03, enabled=1 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 3 0x0c* 0x0d 0x0e
How do these kind of jack handle by UCM ?
http://www.dell.com/support/home/us/en/19/product-support/product/inspiron-1...
6 Headset port Connect a headphone, a microphone, or a headphone and microphone combo (headset).
UCM is not really needed for this device as Pulseaudio handles the standardised HDA jacks and routing (there is nothing stopping a UCM config being defined though). So for each input/output endpoint above you would list it's jack kcontrol in the endpoint device section. e.g. sound server reads jack input and type, checks UCM config and matches the device before setting routing according to UCM device.
When using hda emu and latest alsa driver with https://launchpadlibrarian.net/193669943/AlsaInfo.txt
The driver create capture source control which allow user to select internal mic, headset mic and headphone mic , this control change the function of the combo jack to headphone, headset and mic
If this logic is also applied to those notebook with three physical jack: headset, headphone and mic jack
The user need to select the headset mic , mic and internal mic using capture source control when not using pulseaudio
On Thu, 2015-04-02 at 08:28 -0700, Dylan Reid wrote:
On Wed, Apr 1, 2015 at 5:27 AM, Liam Girdwood liam.r.girdwood@linux.intel.com wrote:
On Tue, 2015-03-31 at 19:49 +0300, Tanu Kaskinen wrote:
So is your preference that UCM configuration authors are forced to define simplex devices to deal with headset jacks, rather than using duplex devices and defining "PlaybackJackControl" and "CaptureJackControl" separately? (I don't personally mind either way.)
I don't really mind either, but what's easier for audio servers like pulseaudio that will be the main UCM clients ? I guess that pulseaudio, CRAS, and other audio servers probably deal with simplex PCM streams internally so mapping to simplex jacks/devices might be better ?
There is an advantage to having a separate device for the headphone and mic even if they are connected to the same jack. The user can enable one and not the other, most commonly to use the headphones but record from the built-in mic, ignoring the headset mic. Because of this we require all ChromeOS devices to support separate reporting and selection of headphone/mic on the headset jack. There is always one UCM device and one user-visible i/o node per jack.
I'm not sure what you mean... "There is always one UCM device [...] per jack" sounds like you want there to be only one device representing headset, but on the other hand you talk about it being advantageous to have a separate device for the headphone and mic... Can you clarify the number of UCM devices per physical headset jack?
On Tue, 2015-04-07 at 23:37 +0300, Tanu Kaskinen wrote:
On Thu, 2015-04-02 at 08:28 -0700, Dylan Reid wrote:
On Wed, Apr 1, 2015 at 5:27 AM, Liam Girdwood liam.r.girdwood@linux.intel.com wrote:
On Tue, 2015-03-31 at 19:49 +0300, Tanu Kaskinen wrote:
So is your preference that UCM configuration authors are forced to define simplex devices to deal with headset jacks, rather than using duplex devices and defining "PlaybackJackControl" and "CaptureJackControl" separately? (I don't personally mind either way.)
I don't really mind either, but what's easier for audio servers like pulseaudio that will be the main UCM clients ? I guess that pulseaudio, CRAS, and other audio servers probably deal with simplex PCM streams internally so mapping to simplex jacks/devices might be better ?
There is an advantage to having a separate device for the headphone and mic even if they are connected to the same jack. The user can enable one and not the other, most commonly to use the headphones but record from the built-in mic, ignoring the headset mic. Because of this we require all ChromeOS devices to support separate reporting and selection of headphone/mic on the headset jack. There is always one UCM device and one user-visible i/o node per jack.
I'm not sure what you mean... "There is always one UCM device [...] per jack" sounds like you want there to be only one device representing headset, but on the other hand you talk about it being advantageous to have a separate device for the headphone and mic... Can you clarify the number of UCM devices per physical headset jack?
Ping? I'd like to get this clarified, because depending on what CRAS does, we may or may not have to change the use-case.h documentation (and PulseAudio code).
On Wed, Apr 15, 2015 at 8:39 AM, Tanu Kaskinen tanu.kaskinen@linux.intel.com wrote:
On Tue, 2015-04-07 at 23:37 +0300, Tanu Kaskinen wrote:
On Thu, 2015-04-02 at 08:28 -0700, Dylan Reid wrote:
On Wed, Apr 1, 2015 at 5:27 AM, Liam Girdwood liam.r.girdwood@linux.intel.com wrote:
On Tue, 2015-03-31 at 19:49 +0300, Tanu Kaskinen wrote:
So is your preference that UCM configuration authors are forced to define simplex devices to deal with headset jacks, rather than using duplex devices and defining "PlaybackJackControl" and "CaptureJackControl" separately? (I don't personally mind either way.)
I don't really mind either, but what's easier for audio servers like pulseaudio that will be the main UCM clients ? I guess that pulseaudio, CRAS, and other audio servers probably deal with simplex PCM streams internally so mapping to simplex jacks/devices might be better ?
There is an advantage to having a separate device for the headphone and mic even if they are connected to the same jack. The user can enable one and not the other, most commonly to use the headphones but record from the built-in mic, ignoring the headset mic. Because of this we require all ChromeOS devices to support separate reporting and selection of headphone/mic on the headset jack. There is always one UCM device and one user-visible i/o node per jack.
I'm not sure what you mean... "There is always one UCM device [...] per jack" sounds like you want there to be only one device representing headset, but on the other hand you talk about it being advantageous to have a separate device for the headphone and mic... Can you clarify the number of UCM devices per physical headset jack?
Ping? I'd like to get this clarified, because depending on what CRAS does, we may or may not have to change the use-case.h documentation (and PulseAudio code).
Sorry I missed this. CRAS handles separate UCM devices for the headphone and mic of a combo jack. However there is no support for handling a "Headset Jack" kcontrol or input event. We have ensured all our platforms are capable of detecting if a mic is present and that they report the headphone and mic as separate jacks.
-- Tanu
On Wed, 2015-04-15 at 09:10 -0700, Dylan Reid wrote:
On Wed, Apr 15, 2015 at 8:39 AM, Tanu Kaskinen tanu.kaskinen@linux.intel.com wrote:
On Tue, 2015-04-07 at 23:37 +0300, Tanu Kaskinen wrote:
I'm not sure what you mean... "There is always one UCM device [...] per jack" sounds like you want there to be only one device representing headset, but on the other hand you talk about it being advantageous to have a separate device for the headphone and mic... Can you clarify the number of UCM devices per physical headset jack?
Ping? I'd like to get this clarified, because depending on what CRAS does, we may or may not have to change the use-case.h documentation (and PulseAudio code).
Sorry I missed this. CRAS handles separate UCM devices for the headphone and mic of a combo jack. However there is no support for handling a "Headset Jack" kcontrol or input event. We have ensured all our platforms are capable of detecting if a mic is present and that they report the headphone and mic as separate jacks.
Thanks, no need to change anything then! (At least for now.)
participants (7)
-
Dylan Reid -
Jie, Yang -
Liam Girdwood -
Mark Brown -
Raymond Yau -
Takashi Iwai -
Tanu Kaskinen