Separate input and output jacks for one UCM device?

Separate input and output jacks for one UCM device?

[Tanu Kaskinen]

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

-- 
Tanu

Re: Separate input and output jacks for one UCM device?

[Liam Girdwood]

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

Re: Separate input and output jacks for one UCM device?

[Takashi Iwai]

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

Re: Separate input and output jacks for one UCM device?

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 891 bytes --]

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

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Separate input and output jacks for one UCM device?

[Jie, Yang]

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

Re: Separate input and output jacks for one UCM device?

[Jie, Yang]

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

Re: Separate input and output jacks for one UCM device?

[Takashi Iwai]

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

Re: Separate input and output jacks for one UCM device?

[Takashi Iwai]

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

Re: Separate input and output jacks for one UCM device?

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 558 bytes --]

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.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Separate input and output jacks for one UCM device?

[Takashi Iwai]

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

Re: Separate input and output jacks for one UCM device?

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 805 bytes --]

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").

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Separate input and output jacks for one UCM device?

[Takashi Iwai]

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

Re: Separate input and output jacks for one UCM device?

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 382 bytes --]

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

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Separate input and output jacks for one UCM device?

[Raymond Yau]

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

Re: Separate input and output jacks for one UCM device?

[Tanu Kaskinen]

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

-- 
Tanu

Re: Separate input and output jacks for one UCM device?

[Liam Girdwood]

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

Re: Separate input and output jacks for one UCM device?

[Tanu Kaskinen]

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.

-- 
Tanu

Re: Separate input and output jacks for one UCM device?

[Raymond Yau]

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

Re: Separate input and output jacks for one UCM device?

[Liam Girdwood]

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

Re: Separate input and output jacks for one UCM device?

[Dylan Reid]

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

Re: Separate input and output jacks for one UCM device?

[Raymond Yau]

> >> >
> >> > 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-15-3537/manuals

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

Re: Separate input and output jacks for one UCM device?

[Liam Girdwood]

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-15-3537/manuals
> 
> 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

Re: Separate input and output jacks for one UCM device?

[Raymond Yau]

> >
> > How do these kind of jack handle by UCM ?
> >
> >
http://www.dell.com/support/home/us/en/19/product-support/product/inspiron-15-3537/manuals
> >
> > 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-daemon/trunk/view/head:/plugins/media-keys/what-did-you-plug-in/pa-backend.c

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-14/manuals

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

Re: Separate input and output jacks for one UCM device?

[Tanu Kaskinen]

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?

-- 
Tanu

Re: Separate input and output jacks for one UCM device?

[Raymond Yau]

> > > >
> >
> > How do these kind of jack handle by UCM ?
> >
> >
http://www.dell.com/support/home/us/en/19/product-support/product/inspiron-15-3537/manuals
> >
> > 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

Re: Separate input and output jacks for one UCM device?

[Tanu Kaskinen]

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

-- 
Tanu

Re: Separate input and output jacks for one UCM device?

[Dylan Reid]

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
>

Re: Separate input and output jacks for one UCM device?

[Tanu Kaskinen]

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

-- 
Tanu