Subject: Re: Ideas on the audio framework
To: None <email@example.com>
From: Jukka Marin <firstname.lastname@example.org>
Date: 12/12/2004 14:03:33
On Sun, Dec 12, 2004 at 12:09:20PM +0100, email@example.com wrote:
> That's exactly the change I committed to the ac97 mixers about a year
> ago. The issue is, it's very hard to do that with stateless mixers,
> and I can't say I'm really satisfied with the result, but at least it
> allows OSS applications to work to some extent in some situations.
IMHO, the mixer should save the volume level supplied by the application
(without scaling), so the same value can be read back by the application.
This value would then be scaled and written to the hardware register.
> Jukka said he didn't know any up/down applications. I know two of
> them: mp3blaster and mplayer.
Hmm, I have used mplayer.. I guess I use xmmix (and mixerctl) to adjust
volume even with mplayer..
There should probably be a way of asking how many steps (in the 0...255
scale) one hardware step is, so you could increment the volume by one
hardware step of you really wanted to. (On the other hand, this would
make the averaged increment steps different size with different hardware.)
> Both had the issue that the granularity of their own mixer change was
> not enough to allow the volume to be pushed up, so I added a guess in
> ac97.c to actually change the volume in that situation.
> But I let you look at the downside of this:
> for i in `jot 45 150`; do mixerctl -w outputs.master=$i; done
I wonder if this is what I'm seeing with xmmix, too..
More thoughts about the audio system: When you have several audio cards on
one machine, you'll end up with multiple /dev/mixerN devices - fine. But
on the application level, this means more work: you need to open multiple
mixer devices or run multiple applications in parallel (like I have to do
with xmmix). It would be nice to be able to combine all the audio hardware
present as one device with multiple inputs and outputs. Ultimately, it
would be possible to name the inputs and outputs intuitively, but I guess
passing information to kernel from /etc/audioconfig or some such would not
please everyone.. ;)