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

[Jon Trulson]

On Tue, 25 Jul 2006, Erik Auerswald wrote:

> Hi,
>
> I've read this mail after the others referring to a list of MixerInit
> values... the joys of a threaded mail client. ;-)
>
> On Mon, Jul 24, 2006 at 06:41:09PM -0600, Jon Trulson wrote:
>> On Mon, 24 Jul 2006, Erik Auerswald wrote:
>>> On Sun, Jul 23, 2006 at 10:29:07PM -0600, Jon Trulson wrote:
>>>> On Mon, 24 Jul 2006, Erik Auerswald wrote:
>>>>>
>> [...]
[...]

> Right now NAS will restore the last NAS settings.
>
>>         It seems to me, that this is the behavior that you do not
>>         like?
>
> I prefer the way it is now (ignoring the initialization part for this
> statement). I would not want NAS to revert the changes I made to the NAS
> settings.
>


         Ok... I have no problem with the last* stuff, though I can see
         where Paul is coming from, so that should be supported as well.

>>         Hehe, I actually like this behaviour... I'd even prefer one
>>         further and have NAS reset to the defaults on every server
>>         iteration (essentially whenever NAS opens the device), not
>>         caring about what previous NAS client did, in case some
>>         nas/non-nas set the volume to low for me to hear what
>>         'festival' is telling me :)
>
> In this case I'd say use auctl just before festival to set the right
> gain for festival.
>

         Hehe.  I would really rather not fire off new processes where
         I didn't have to before, but in my case it's generally ok with
         the last* stuff.  The main offenders are non-NAS apps - I like
         NAS keeping it's own mixer settings and restoring them
         (last*).

         Ultimately, I'd like the default gains to be re-established on
         every open, but that's just me.

>>         So, right now MixerInit simply sets/doesnotset the RECSRC.
>>         Perhaps this needs to be expanded:
>
> And the RECSRC should be controllable via NAS even if MixerInit is set
> to "no" IMHO.
>

         I think all the mixer settings should be controllable, even if
         mixerinit == no.  mixer==no should just mean to use whatever
         the current mixer settings are, but allow changing them under
         nas client control.

         The only case where no mixer setting should ever be executed
         is if specifically configured (either by changing to a bogus
         mixer device in nas.conf, or a new option/new mixerinit mode.


>>         Assuming I were to make MixerInit handle an integers well as
>>         a bool:
>>
>>         0 = do not modify mixer characteristics at startup at all.
>>             Use whatever is there.
>
> I've sent a patch to the list to do just that when MixerInit is "no". We
> could continue work on this and implement the other modes as well.
>

         You bet :)



-- 
Jon Trulson
mailto:jon at radscan.com http://radscan.com/~jon
#include <std/disclaimer.h>
"No Kill I" -Horta