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

[Liam Girdwood <liam.r.girdwood@linux.intel.com>]

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