Re: Problem with multiopen on SB Audigy 2

[Jaroslav Kysela <perex@suse.cz>]

On Wed, 8 Oct 2003, Takashi Iwai wrote:

> 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.

Yes, I think that we might use the kernel to create the "user defined"
controls which can be created from the user space. In this case, we can
nicely do all kinds of abstractions in the user space.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
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