[nas] [PATCH] changed method of setting the input gain

[Erik Auerswald]

Hi,

On Tue, Jul 25, 2006 at 06:31:06PM -0600, Jon Trulson wrote:
> On Tue, 25 Jul 2006, Paul Fox wrote:
> >erik wrote:
> >> On Mon, Jul 24, 2006 at 11:12:18PM -0400, Paul Fox wrote:
> >> >     - i want nas to always use *and report* the current mixer settings.
> >> > 	if another app uses and adjusts the mixer, i want nas to notice
> >> > 	that, so that clients can see that it's happened.
> >>
> >> The only way to achieve this is to keep the mixer device open. I would
> >> be happy with this as well since then NAS mixer changes would immediatly
> >> affect the audio hardware. The setting of last used values on reopen
> >> would then not be necessary.
> >>
> >> Several programs can use the mixer device at the same time so this
> >> should not be problematic.
> >
> >ah.  i think this was the missing piece, for me -- that while only
> >one program can have the pcm device open, more than one can have the
> >mixer open.
> >
> >do you think it even needs to be configurable?  any reason not to
> >just leave the mixer open all the time (assuming we're not configured
> >to never use it at all)?  if configurable, it seems like it should
> >be a boolean, separate from the mixerinit options being discussed.

I'd say it does not need to be configurable. I've just checked the OSS
programming manual and it's official thet several programms can open the
mixer device at the same time. And I agree that a seperate boolean
should be used if it should be configurable nevertheless.

>         If this can be done (track mixer changes), and mixer usage is
>         configured to be allowed, then it should 'just work', no
>         option neccessary.  IMO of course.

That can be done. In the getPhysical* functions the mixer can be
queried. We would not need the last* variables any more (I think). I've
already tested this for the output gain and can come up with a patch.
I'll wait for the re-indentation patch first. ;-)

> >btw, i think i like the idea of having finer-grained boolean options,
> >rather than a large set of mixerinit values.  but you two have a idea
> >of how that should work, so i'll leave that up to you.
> 
>   Aww common!  I love yacc'ing around in config... :)

I'm in favour of finer grained boolean options whenever the controlled
features are independent. I'm not too sure about the mixer (re-)
initialization. We could use a MixerReInit option that does whatever is
specified by MixerInit on any reopen of the audio device. But the
combination MixerInit no, MixerReInit yes would be a bit strange.

Erik