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