Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: James Courtier-Dutton <James@superbug.co.uk>
To: Jaroslav Kysela <perex@suse.cz>
Cc: Takashi Iwai <tiwai@suse.de>,
	alsa-devel <alsa-devel@lists.sourceforge.net>
Subject: Re: Mixer improvements
Date: Sat, 17 Sep 2005 19:39:47 +0100	[thread overview]
Message-ID: <432C62F3.3050302@superbug.co.uk> (raw)
In-Reply-To: <Pine.LNX.4.61.0509121434440.9569@tm8103.perex-int.cz>

Jaroslav Kysela wrote:
> On Mon, 12 Sep 2005, Takashi Iwai wrote:
> 
> 
>>>1) Unsigned integer index to percent <-> dB function.
>>>2) Integer for Analog or Digital path. This will indicate which side of 
>>>3) Link information.
>>>4) Alternatively, we could implement this in alsa-lib, and just add 
> 
> 
> I agree that 1 is the main required extension. 2 and 3 are optional in my 
> eyes.

Agreed.

> 
> 
>>Moreover, we should be careful to handle the value <-> dB conversion.
>>The dB isn't integer in general, and defining the fixed resolution is
>>no generic solution.
> 
> 
> It's signed integer - fixed float resolution (* 100) in my implementation. 
> I think that it's enough for our purpose.

I have already checked into the alsa-utils cvs support for this API in 
alsamixer. We just need to add the features to alsa-lib and alsa-driver.

> 
> 
>>Adding a dB info into the driver would be required for the USB and HDA 
>>stuff, at least, since they can (or need) retrieve such information from 
>>the hardware directly. Meanwhile, others are basically given statically 
>>- e.g. a simple table look-up for each ac97 codec.  This isn't 
>>necessarily in the kernel code at all.

> 
> 
> I agree, the alsa-lib should have a database containing this static 
> information. Also, I think that this information does not belong to the 
> universal control API at all. We need to decide, if we need another 
> midlevel module providing this information, or in my eyes, better way 
> might be to use the hwdep device and pass this information to the user 
> space. The alsa-lib modules driving the specific hardware will parse this 
> information and do own things with it. Perhaps, we can pass simple text 
> from the driver to user space. In this way, the procfs or devfs might be 
> used.
> 
> 						Jaroslav
> 

I will take a first bash at it, provide some patch code that we can then 
discuss.

James


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

      parent reply	other threads:[~2005-09-17 18:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-11 11:51 Mixer improvements James Courtier-Dutton
2005-09-12 12:25 ` Takashi Iwai
2005-09-12 12:44   ` Jaroslav Kysela
2005-09-12 12:57     ` Takashi Iwai
2005-09-17 18:39     ` James Courtier-Dutton [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=432C62F3.3050302@superbug.co.uk \
    --to=james@superbug.co.uk \
    --cc=alsa-devel@lists.sourceforge.net \
    --cc=perex@suse.cz \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox