Only one element for multichannel mixer controls please!

Only one element for multichannel mixer controls please!

[Lennart Poettering]

Heya!

It seems that quite a few ALSA drivers for multichannel sound cards
export three seperate stereo mixer controls to control front, rear and
center/lfe independantly. That sucks because a client (such as
PulseAudio) cannot make use of this. Instead they should export a
single 6ch mixer control!

The "amixer scontents" output looks very strange for these drivers
since it lists a "Rear" control that as a "Front Left" and a "Front
Right" channel. So, what is it now: front or rear?

Is there any reason for this current driver behaviour? I mean, the
mixer knows channel ids like SND_MIXER_SCHN_REAR_LEFT perfectly
well. Or is it that those devices have some devices joined and this
cannot be expressd with a single boolean "joined" for each
control?

Please enlighten me!

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Only one element for multichannel mixer controls please!

[Takashi Iwai]

At Sat, 25 Oct 2008 01:49:33 +0200,
Lennart Poettering wrote:
> 
> Heya!
> 
> It seems that quite a few ALSA drivers for multichannel sound cards
> export three seperate stereo mixer controls to control front, rear and
> center/lfe independantly. That sucks because a client (such as
> PulseAudio) cannot make use of this. Instead they should export a
> single 6ch mixer control!

Depends.  For casual users, left/right and rear left/right grouping
is more natural way than all separated mixer controls.

> The "amixer scontents" output looks very strange for these drivers
> since it lists a "Rear" control that as a "Front Left" and a "Front
> Right" channel. So, what is it now: front or rear?
> 
> Is there any reason for this current driver behaviour? I mean, the
> mixer knows channel ids like SND_MIXER_SCHN_REAR_LEFT perfectly
> well. Or is it that those devices have some devices joined and this
> cannot be expressd with a single boolean "joined" for each
> control?

All these are about the channel abstrcation.
And, the current smixer abstraction sucks.  Really.


Takashi

Re: Only one element for multichannel mixer controls please!

[Jaroslav Kysela]

On Mon, 27 Oct 2008, Takashi Iwai wrote:

> And, the current smixer abstraction sucks.  Really.

Because we do not have any abstraction available at this moment. The 
smixer API is not bad itself, it's just about internal alsa-lib code and 
how to implement abstraction layers. Also, for applications using PCM 
devices we need to add two functions handling all used channels like this:

/* for PCM stream volume control */
int snd_pcm_mixer_element(snd_pcm_t *pcm, snd_mixer_t *mixer, snd_mixer_elem_t **elem);
/* for Master volume control - will not be available for recording */
int snd_pcm_mixer_master(snd_pcm_t *pcm, snd_mixer_t *mixer, snd_mixer_elem_t **elem);

My idea is to describe the correlations between PCM and mixer in the 
standard .conf files defining PCM devices.

The internal smixer interface can be extended using dynamic C library now, 
but the question is, who will write C modules for all cards. I also
prepared python interface to allow fast smixer prototyping. Another 
possibility is to create a C module which will parse a text configuration
file describing the abstaction.

					Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: Only one element for multichannel mixer controls please!

[Takashi Iwai]

At Mon, 27 Oct 2008 09:53:30 +0100 (CET),
Jaroslav Kysela wrote:
> 
> On Mon, 27 Oct 2008, Takashi Iwai wrote:
> 
> > And, the current smixer abstraction sucks.  Really.
> 
> Because we do not have any abstraction available at this moment. The 
> smixer API is not bad itself, it's just about internal alsa-lib code and 
> how to implement abstraction layers. Also, for applications using PCM 
> devices we need to add two functions handling all used channels like this:
> 
> /* for PCM stream volume control */
> int snd_pcm_mixer_element(snd_pcm_t *pcm, snd_mixer_t *mixer, snd_mixer_elem_t **elem);
> /* for Master volume control - will not be available for recording */
> int snd_pcm_mixer_master(snd_pcm_t *pcm, snd_mixer_t *mixer, snd_mixer_elem_t **elem);
> 
> My idea is to describe the correlations between PCM and mixer in the 
> standard .conf files defining PCM devices.
> 
> The internal smixer interface can be extended using dynamic C library now, 
> but the question is, who will write C modules for all cards. I also
> prepared python interface to allow fast smixer prototyping. Another 
> possibility is to create a C module which will parse a text configuration
> file describing the abstaction.

Yes, I know these.  Still, nothing is there over years.  And I'm
afraid of being so forever.

IMHO, a big part of the problem is its overly complex layers and
old-style mixer API (in addition to complete lack of documentation).
The plugin solution doesn't work well because you are tring to graft
orange and apple.


Takashi

Re: Only one element for multichannel mixer controls please!

[Jaroslav Kysela]

On Mon, 27 Oct 2008, Takashi Iwai wrote:

> IMHO, a big part of the problem is its overly complex layers and

I agree. Some layers should be merged and simplified.

> old-style mixer API (in addition to complete lack of documentation).

I don't understand what you mean old-style API. API inside alsa-lib or 
smixer API for applications? If it's the second case, what you imagine as 
right mixer API for apps?

> The plugin solution doesn't work well because you are tring to graft
> orange and apple.

Please, explain.

					Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: Only one element for multichannel mixer controls please!

[Takashi Iwai]

At Mon, 27 Oct 2008 10:20:48 +0100 (CET),
Jaroslav Kysela wrote:
> 
> On Mon, 27 Oct 2008, Takashi Iwai wrote:
> 
> > IMHO, a big part of the problem is its overly complex layers and
> 
> I agree. Some layers should be merged and simplified.
> 
> > old-style mixer API (in addition to complete lack of documentation).
> 
> I don't understand what you mean old-style API. API inside alsa-lib or 
> smixer API for applications? If it's the second case, what you imagine as 
> right mixer API for apps?

In my mind, mostly about the external API:
- what if an element has 2 switches but 4 volumes?
- are common, playback and capture exclusive?
- exclusive switch is often messy; whether it's a radio button or a list,
  it's a question of UI, not about API - a list is more appropriate
- why attach/deteach/load ops needed in addition to open/close?
- why hctl?
- what is mixer class and why necessary?
- why both snd_mixer_elem and snd_mixer_selem exist?

But, about internal API, too:
- the abstraction concept is nowhere documented
- the internal API is nowhere documented
- simple_none.c is still buggy (the common elements aren't handled
  properly any existing mixer apps including alsamixer)

> > The plugin solution doesn't work well because you are tring to graft
> > orange and apple.
> 
> Please, explain.

Well, in your scenario, each driver writer is supposed to create a new
C smixer plugin.  But, providing both is a hard work because they are
really two different things.  In the current situation without any
good information how and what to do, grafting two different things
doesn't work well.

The plugin framework is pretty simple.  But, this means that you owe
so many things (almost everything) in the plugin itself.  That's why
no one can start on it.  At least, we need good examples codes and a
good helper library for that.


Takashi

Re: Only one element for multichannel mixer controls please!

[Jaroslav Kysela]

On Mon, 27 Oct 2008, Takashi Iwai wrote:

> At Mon, 27 Oct 2008 10:20:48 +0100 (CET),
> Jaroslav Kysela wrote:
> > 
> > On Mon, 27 Oct 2008, Takashi Iwai wrote:
> > 
> > > IMHO, a big part of the problem is its overly complex layers and
> > 
> > I agree. Some layers should be merged and simplified.
> > 
> > > old-style mixer API (in addition to complete lack of documentation).
> > 
> > I don't understand what you mean old-style API. API inside alsa-lib or 
> > smixer API for applications? If it's the second case, what you imagine as 
> > right mixer API for apps?
> 
> In my mind, mostly about the external API:
> - what if an element has 2 switches but 4 volumes?

Do we need to handle such situation? If we start to describe the exact 
routes we end in more deep hell. I would propose to leave mapping 1:1 and 
join requests for 2 switches together (with eventual value change event 
returned back to app). Eventually, we can return a volume/switch map to 
application which controls are joined.

> - are common, playback and capture exclusive?

It's just about to add one function returning this information.

> - exclusive switch is often messy; whether it's a radio button or a list,
>   it's a question of UI, not about API - a list is more appropriate

We need to add this to documentation.

> - why attach/deteach/load ops needed in addition to open/close?
> - why hctl?
> - what is mixer class and why necessary?
> - why both snd_mixer_elem and snd_mixer_selem exist?

It's exactly what I meant by simplification and merging. Anyway, all 
mentioned things are mostly cosmetic. They imply no dramatic changes for 
applications.

> But, about internal API, too:
> - the abstraction concept is nowhere documented
> - the internal API is nowhere documented
> - simple_none.c is still buggy (the common elements aren't handled
>   properly any existing mixer apps including alsamixer)
>
> > > The plugin solution doesn't work well because you are tring to graft
> > > orange and apple.
> > 
> > Please, explain.
> 
> Well, in your scenario, each driver writer is supposed to create a new
> C smixer plugin.  But, providing both is a hard work because they are
> really two different things.  In the current situation without any
> good information how and what to do, grafting two different things
> doesn't work well.
> 
> The plugin framework is pretty simple.  But, this means that you owe
> so many things (almost everything) in the plugin itself.  That's why
> no one can start on it.  At least, we need good examples codes and a
> good helper library for that.

I agree, it's time to create a helper library and some documentation (or 
better documented code example).

					Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: Only one element for multichannel mixer controls please!

[Takashi Iwai]

At Mon, 27 Oct 2008 11:12:59 +0100 (CET),
Jaroslav Kysela wrote:
> 
> On Mon, 27 Oct 2008, Takashi Iwai wrote:
> 
> > At Mon, 27 Oct 2008 10:20:48 +0100 (CET),
> > Jaroslav Kysela wrote:
> > > 
> > > On Mon, 27 Oct 2008, Takashi Iwai wrote:
> > > 
> > > > IMHO, a big part of the problem is its overly complex layers and
> > > 
> > > I agree. Some layers should be merged and simplified.
> > > 
> > > > old-style mixer API (in addition to complete lack of documentation).
> > > 
> > > I don't understand what you mean old-style API. API inside alsa-lib or 
> > > smixer API for applications? If it's the second case, what you imagine as 
> > > right mixer API for apps?
> > 
> > In my mind, mostly about the external API:
> > - what if an element has 2 switches but 4 volumes?
> 
> Do we need to handle such situation? If we start to describe the exact 
> routes we end in more deep hell. I would propose to leave mapping 1:1 and 
> join requests for 2 switches together (with eventual value change event 
> returned back to app). Eventually, we can return a volume/switch map to 
> application which controls are joined.

A primary question is: Is this mixer abstraction supposed to be as
generic as possible, or to make desktop-apps (not "pro-audio")
programmer's life happier?

> > - are common, playback and capture exclusive?
> 
> It's just about to add one function returning this information.

Hmm, I'm confused.  There are cases that both independent playback and
capture volumes are provided, and the cases where volumes are
irrelevant with playback/capture direction.  I thought the "common"
corresponds to the latter.

> > - exclusive switch is often messy; whether it's a radio button or a list,
> >   it's a question of UI, not about API - a list is more appropriate
> 
> We need to add this to documentation.

It's not about the documentation but about the implementation.
For example, the smixer gives exclusive switches from "Capture Source"
enum.  This is really annoying.

OTOH, the exiting apps already assume that these switches (but often
even don't check the exclusivity!), so we can't break this always.
This is why I think it sucks.  We stuck.  Yeah, we can say "fix apps".
But we know that this never works.

> > - why attach/deteach/load ops needed in addition to open/close?
> > - why hctl?
> > - what is mixer class and why necessary?
> > - why both snd_mixer_elem and snd_mixer_selem exist?
> 
> It's exactly what I meant by simplification and merging. Anyway, all 
> mentioned things are mostly cosmetic. They imply no dramatic changes for 
> applications.

Yeah, I don't want to impact too much application side at all, too.
If we were allowed, we should rewrite every alsa-lib API :)


> > But, about internal API, too:
> > - the abstraction concept is nowhere documented
> > - the internal API is nowhere documented
> > - simple_none.c is still buggy (the common elements aren't handled
> >   properly any existing mixer apps including alsamixer)
> >
> > > > The plugin solution doesn't work well because you are tring to graft
> > > > orange and apple.
> > > 
> > > Please, explain.
> > 
> > Well, in your scenario, each driver writer is supposed to create a new
> > C smixer plugin.  But, providing both is a hard work because they are
> > really two different things.  In the current situation without any
> > good information how and what to do, grafting two different things
> > doesn't work well.
> > 
> > The plugin framework is pretty simple.  But, this means that you owe
> > so many things (almost everything) in the plugin itself.  That's why
> > no one can start on it.  At least, we need good examples codes and a
> > good helper library for that.
> 
> I agree, it's time to create a helper library and some documentation (or 
> better documented code example).

Yep, but the helper library would be just the second step.  The first
step is to create a plugin that really works well.


HOWEVER: before we go on, maybe now is a good time to consider the
biggest problem we have.

Suppose you are an app programmer.  A common question would be:
  "how can I change the volume of my application?"  
Do you have an answer that works 100% reliably?  I don't.

A next question would be:
  "how can I set up a recording from the front mic on my application?"
I have no 100% working answer, too.

There would be more such simple question.  And I think we have no
answer to all of them.

Certainly the current API isn't designed to serve for such things.
Why?  *We* need the answer for that...


thanks,

Takashi