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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.