Re: Problem with multiopen on SB Audigy 2

[Takashi Iwai <tiwai@suse.de>]

At Wed, 8 Oct 2003 17:44:41 +0200 (CEST),
Jaroslav wrote:
> 
> On Wed, 8 Oct 2003, Takashi Iwai wrote:
> 
> > At Wed, 8 Oct 2003 16:44:02 +0200 (CEST),
> > Jaroslav wrote:
> > >
> > > On Wed, 8 Oct 2003, Takashi Iwai wrote:
> > >
> > > > > I'm still not sure, if we should handle these things in the driver.
> > > > > Hardware is not designed in this way and we should describe hardware
> > > > > in the driver as most accurate as we can.
> > > >
> > > > IMO, the master volume is a feature we mostly need.
> > > > in the case of emu10k1, it's much easier to implement this on the
> > > > driver (as a digital attenuator) rather than implementing it outside
> > > > the kernel space (except for the lack of GPR space).
> > >
> > > Ok, but add more channels to "Master" so we have still a chance to control
> > > values independently.
> >
> > now i'm thinking of a hierarchy like
> >
> > 	master (mono?)
> >
> > 	front(l/r)  rear(l/r) center/lfe ...
> >
> > 	outputs...
> >
> > the advantage is that you can adjust all volumes with a single
> > control.  adjusting the level for each channel is done by the volumes
> > below it.  there is still a problem that the sensitivity is different
> > between front and surround volumes (the former is ac97 and the latter
> > is the digital attenuation).  perhaps it's solved when we introduce dB
> > hints.
> >
> > or, yes, instead of the top master, we merge all the lower layers as
> > the master volume (either multi-channels or "master front", "master
> > rear", etc.)
> >
> > perhaps we should create some templates of basic mixer designs suited
> > to different hardware implementations.  the confusion we're facing now
> > seems to come from the different implementation even though the same
> > control name is used.
> 
> Yes, but again, why to try to solve these things in the kernel space?
> There is no point to do it there and also we can modify simple API to use
> hints written in lisp to handle the special cases - like covered in
> this discussion.

the template i meant above is the basic designs of control naming, and
i don't mean that this is the kernel issue.  (well, in the case of
"master" volume, we cannot handle it simply by abstraction but need a
new control, though.)

i believe it's just a question which is easier to implement.
i agree that almost all cases can be solved by a higher abstraction,
and i prefer that, too.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php