From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jaroslav Kysela Subject: Re: Problem with multiopen on SB Audigy 2 Date: Wed, 8 Oct 2003 17:44:41 +0200 (CEST) Sender: alsa-devel-admin@lists.sourceforge.net Message-ID: References: <3F82F126.4000800@superbug.demon.co.uk> <3F833B40.9070009@superbug.demon.co.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-path: In-Reply-To: Errors-To: alsa-devel-admin@lists.sourceforge.net List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: To: Takashi Iwai Cc: James Courtier-Dutton , alsa-devel List-Id: alsa-devel@alsa-project.org 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. Jaroslav ----- Jaroslav Kysela 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