[alsa-devel] Master vs. Front/Rear/LFE/... elements
perex at perex.cz
Tue May 12 10:02:42 CEST 2009
On Tue, 12 May 2009, James Courtier-Dutton wrote:
> 2009/5/7 Takashi Iwai <tiwai at suse.de>:
>> IMO, the best would be a total rewrite of the current mixer API, as I
>> mentioned some times. Right now it's more complicated than needed,
>> but not powerful enough to handle exceptional cases.
>> I know designing a generic and fully-working API is pretty difficult,
> Isn't that a bit of overkill.
> I don't think the API is the problem.
> I thought about re-writing the API mixer api when I was updating the
> alsamixer.c for dB settings.
> When you look into it in more detail, there really is no easy way to
> do a better api than the one we already have and still support all the
> different sound cards out there.
> For pro applications, one also has large USB attached mixer control
> decks, with sliders etc, and one would have to write code to ensure
> they link up correctly with the correct mixer controls. I.e. A user
> moves a slider on the control deck, and it moves the correct slider in
> I think what we really do need is a global definition of each control.
> I.e. Master Playback control
> 1) Must exist.
> 2) Adds another gain/attenuation after the "front, side, rear etc."
> controls. (I.e between the front control and the speaker.
> 3) Should the control be presented as 3 stereo controls, or one 6
> channel control?
> 4) Is the control linked to a PCM, or is it a global control on the
> output side of the sound chip.
> I would like to see a global "Speaker arrangement" setting, where the
> user can tell alsa how they have their speakers arranged. E.g. They
> have 2 speakers, or they have 5.1 speakers, or that have 2 speakers
> and one set of headphones and where each are plugged in. The driver
> would restrict the options depending on the hardware possibilities.
> The alsa mixer could then present a consistent view in each case.
> Once we have the global definition, we can then fix each driver to
> comply with it. In some cases we will have to add virtual controls.
> I.e. Create a software master control and use software to make it
> behave like a real hardware control.
> I think this global definition is all that PA really needs. They can
> then implement it using a single method, and then they can highlight
> all the sound card drivers that need fixing to match it.
> I personally think that the user should set the global speaker
> settings, the master, front, rear etc. controls and then just leave
> I think applications should only control their own PCM channel volume,
> and not touch the master volume at all. PA could then further control
> PCM channel volumes, by for example automatically attenuating the
> sound of an application when it gets put in the backround, if the user
> so wishes. Applications should not have to talk to the alsa mixer at
> all. Just modify a value associated with the PCM stream they are
> outputting to adjust its gain/attenuation.
> int value;
> handle = snd_pcm_open();
> snd_pcm_set_hwparam/swparams etc.;
> snd_pcm_set_gain(handle, &value);
> snd_pcm_get_gain(handle, &value);
> That should be all the user app or PA needs to do
> The user app should not have to talk to the alsa mixer api at all.
> Only a single global mixer control app should need to do that.
In my opinion, it would be better to offer a reduced mixer for playback
and capture PCMs. Something like:
int snd_amixer_open(snd_amixer_t **amixer, const char *name,
snd_pcm_t *playback_pcm, snd_pcm_t *capture_pcm,
For playback, 2 controls will be available:
Master - master playback volume
PCM - PCM stream volume
For capture, a set of controls bellow will be available:
Capture - capture volume
Source - source (enum list)
### - other mixed sources (volume (optional) + switch (required))
If some pcm handle is zero, the mixer direction might be skipped.
If both pcm handles are zero, global mixer will be available to app.
The reasons to pass partial mixer to app:
value change event handling
Jaroslav Kysela <perex at perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.
More information about the Alsa-devel