[alsa-devel] 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 at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel