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