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

[Paul Fox]

here's my initial response to erik.  i'm still digesting jon's
responses.  i have a feeling there's something i'm missing, but
haven't put my finger on it yet.

erik wrote:
 > On Mon, Jul 24, 2006 at 02:59:06PM -0400, Paul Fox wrote:
 > >  > but isn't the point of releasing the device that you want to play
 > >  > well with other users of the device?  in that case, shouldn't you
 > >  > touch nothing at all on a re-acquire of the device?  seems to me
 > 
 > IMHO the NAS server should keep it's settings even if after releasing
 > the sound device. I'd want to allow other programs to use (and change
 > the settings of) the sound device when NAS is not using it, but I would
 > not want this to screw up the settings of the NAS server.

we clearly have very different use cases:  in particular, it's
_exactly_ the case that i'd like to be able to adjust the volume
using a local mixer (e.g., aumix) and have the settings remain
sticky when NAS resumes.  currently things are asymmetric.  if i
run a nas-aware mixer on two client machines:
    clientA$ audiooss aumix
    clientB$ audiooss aumix
and a non-nas-aware mixer on the server:
    server$ aumix
then the one on the server will track changes made in either client, and
the client will track changes made in each other, but they won't track
changes made on the server.

 > If you want to be very polite you could save the current settings and
 > restore them just before releasing the device again.

is this sort of behavior ever the case between two applications
running locally on a sound device?  it's not, in my (admittedly
limited) experience.  it seems like you're trying to use NAS as a
way of pretending you have more than one device, when that isn't
the case.  there's only one device, and mixer control should be
uniform among all apps, local or remote (via nas) that are using the
device.

 > 
 > >  > the server should query the device for current settings when it
 > >  > re-opens, and start from there.
 > 
 > The "mixerinit" option will keep the current mixer settings when first
 > opening the device. The "nomixer" option will always keep the mixer
 > settings and never change them.

never?  not even on client request?

 > 
 > My "consistent gain setting" patches had the reason that I wanted to be
 > able to control the NAS settings even if the device is currently
 > released. This is very useful if the last NAS user left the gain at 100
 > from watching a DVD and my music should be played with gain 30. If the
 > NAS server did not change the settings of a reopened device I would have
 > to endure some much too loud music for the time I need to react to the
 > starting playback.
 > 
 > > looking at the code (for other reasons) i see that this is
 > > complicated by the fact that auvoxware.c goes out of its way to
 > > never ever read the current mixer settings.  it only writes to
 > > them.  seems to me that if the device is being shared with other
 > > applications, that nas should be sharing the levels as well.
 > 
 > Well, it actually reads the levels in initMixer(), but never uses them.
 > This is to be changed by the reworked "mixerinit" option.
 > 
 > NAS is not sharing the device, it is just not blocking it. There is but
 > one user of the sound device at any time. And the useful gain levels can
 > differ a lot between applications.

again, you're treating NAS apps as a different class of app from local
apps.  i don't understand this.

 > 
 > > i'm putting together a patch to implement a "gainscale"
 > > configuration item, which will be a percentage by which all
 > > output gain requests will be reduced.  (this is to keep nas from
 > > causing my sound devices to go into their distortion zone.)

[ this is the patch i just sent to the list, this evening. -pgf ]

 > 
 > Fine. :-)

whew.  :-)  of course, it breaks some of the premise that i've laid out
above, in that anything coming through nas will have a different
permissible mixer range than anything not coming through nas.  so
maybe i'll end up agreeing with you in the end.  :-)


 > > i can also do a patch to eliminate the use of (the recently
 > > renamed :-) "lastPhysicalOutput" variable, in favor of actually
 > > reading the device.
 > 
 > As stated above I would not like this.

i'm getting that impression.  ;-)

could you further describe your use case?  maybe a more concrete
example would help me.  (my use case is simple:  i want to be
able to control the stereo volume uniformly from any computer in
the house, including locally from the non-nas mixer controls local to
the server machine.)

paul
=---------------------
 paul fox, pgf at foxharp.boston.ma.us (arlington, ma, where it's 71.2 degrees)