[alsa-devel] [PATCH 2/2] ALSA: Integrate control based jack reporting with core jack reporting
broonie at opensource.wolfsonmicro.com
Fri Feb 10 16:50:03 CET 2012
On Fri, Feb 10, 2012 at 02:08:52PM +0100, David Henningsson wrote:
> On 02/10/2012 11:55 AM, Takashi Iwai wrote:
> > David Henningsson wrote:
> >> I guess it could be easier to parse if we avoid spaces in names,
> > Exactly, it was the reason.
> Given that the normal desktop user does not usually look at these values
> these days, I'd say being parser friendly weighs heavier than being
> "normal English".
Not all the world is desktop.
> > OTOH, we can take an optional directional suffix, i.e.
> > "[location] base [direction] [channel]", too. For example, base can
> > be "Video" or "Line", and direction can be "Out" or "In".
> > I'd like to hear rather comments from others.
> I think both naming schemes are good, and I'm not too worried about them
> being too verbose. If we run into names being longer than the string
> length we could back off and drop the location, I guess.
It's a complete pain for actually working with them and doing
development - it renders badly in UIs (think about alsamixer for
example, or people looking at things on 80 column terminals) and isn't
friendly to people typing things in.
> If we extend the thought about applying this scheme for mixer control
> names as well, we might run into controls that apply to two outputs but
> not the third, and then the complexity will increase, like "Front
> HP,Line-Out Playback Switch". (And what if the Headphone is located on
> the Front side and the Line-Out is on the back, etc) But then we run
> into the entire story of exposing a graph instead, I guess. :-/
There's no solution except to expose a graph - modern devices are going
to have sufficiently flexible routing that most of the controls have no
association with a particular output (or input for that matter).
More information about the Alsa-devel