All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Takashi Iwai <tiwai@suse.de>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	ALSA development <alsa-devel@alsa-project.org>,
	linuxppc-dev list <linuxppc-dev@ozlabs.org>,
	Benjamin Berg <benjamin@sipsolutions.net>
Subject: Re: [RFC] alsa integer control ranges
Date: Wed, 17 May 2006 08:03:43 +1000	[thread overview]
Message-ID: <1147817023.6753.5.camel@localhost.localdomain> (raw)
In-Reply-To: <s5h7j4m40kf.wl%tiwai@suse.de>

On Tue, 2006-05-16 at 14:27 +0200, Takashi Iwai wrote:
> At Tue, 16 May 2006 14:02:20 +0200,
> Johannes Berg wrote:
> > 
> > Apparently all alsa userspace programs including alsamixer suck. Hence,
> > this patch is required to make them work properly. Why is it so hard to
> > do these additions/subtractions in the program or maybe even in the alsa
> > library? The alsa libraries already think they know better and mess up
> > all kinds of things.
> 
> It's a pretty stupid question to ask why you are stupid :)
> 
> I don't think it's alsa-lib that prevents the negative or non-zero
> integer range.  The fact amixer works implies that it's an
> app-specific bug.  But I'm not 100% sure and need more
> inside-looking.

Well, the problem I think is that pretty much all apps but amixer (and
alsamixer whch works too for me at least) are bogus. It would have been
good if Alsa had a more explicit specification that those values are not
to be interpreted in the old OSS range :) In fact, best would have been
to have the control structure carry a "unit" which a set of known units,
one being dB, since the natural way of specifying an attenuation on any
serious audio HW is dB and is negative... 

> > What are your opinions on this? Should this be required? And if so, why
> > do we even have the value.integer.min when we can't use it anyway? 
> 
> Right now, the range 0-max would make your life easier, I guess.
> 
> The min value is an API definition, and implemented and worked once.
> But no drivers used yet.  So, there might be a breakage.  It's of
> course to be fixed.

There is a lack of serious/professional audio drivers in the linux world
unfortunately... 

Ben.




-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Takashi Iwai <tiwai@suse.de>
Cc: linuxppc-dev list <linuxppc-dev@ozlabs.org>,
	Johannes Berg <johannes@sipsolutions.net>,
	ALSA development <alsa-devel@alsa-project.org>,
	Benjamin Berg <benjamin@sipsolutions.net>
Subject: Re: [Alsa-devel] [RFC] alsa integer control ranges
Date: Wed, 17 May 2006 08:03:43 +1000	[thread overview]
Message-ID: <1147817023.6753.5.camel@localhost.localdomain> (raw)
In-Reply-To: <s5h7j4m40kf.wl%tiwai@suse.de>

On Tue, 2006-05-16 at 14:27 +0200, Takashi Iwai wrote:
> At Tue, 16 May 2006 14:02:20 +0200,
> Johannes Berg wrote:
> > 
> > Apparently all alsa userspace programs including alsamixer suck. Hence,
> > this patch is required to make them work properly. Why is it so hard to
> > do these additions/subtractions in the program or maybe even in the alsa
> > library? The alsa libraries already think they know better and mess up
> > all kinds of things.
> 
> It's a pretty stupid question to ask why you are stupid :)
> 
> I don't think it's alsa-lib that prevents the negative or non-zero
> integer range.  The fact amixer works implies that it's an
> app-specific bug.  But I'm not 100% sure and need more
> inside-looking.

Well, the problem I think is that pretty much all apps but amixer (and
alsamixer whch works too for me at least) are bogus. It would have been
good if Alsa had a more explicit specification that those values are not
to be interpreted in the old OSS range :) In fact, best would have been
to have the control structure carry a "unit" which a set of known units,
one being dB, since the natural way of specifying an attenuation on any
serious audio HW is dB and is negative... 

> > What are your opinions on this? Should this be required? And if so, why
> > do we even have the value.integer.min when we can't use it anyway? 
> 
> Right now, the range 0-max would make your life easier, I guess.
> 
> The min value is an API definition, and implemented and worked once.
> But no drivers used yet.  So, there might be a breakage.  It's of
> course to be fixed.

There is a lack of serious/professional audio drivers in the linux world
unfortunately... 

Ben.

  reply	other threads:[~2006-05-16 22:03 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-16 12:02 [RFC] alsa integer control ranges Johannes Berg
2006-05-16 12:27 ` [Alsa-devel] " Takashi Iwai
2006-05-16 22:03   ` Benjamin Herrenschmidt [this message]
2006-05-16 22:03     ` Benjamin Herrenschmidt
2006-05-17  9:59     ` Takashi Iwai
2006-05-17  9:59       ` [Alsa-devel] " Takashi Iwai
2006-05-17 12:16       ` Johannes Berg
2006-05-17 12:16       ` [Alsa-devel] " Johannes Berg
2006-05-17 12:35         ` Takashi Iwai
2006-05-17 12:35         ` [Alsa-devel] " Takashi Iwai
2006-05-17 12:39           ` Johannes Berg
2006-05-17 12:39             ` [Alsa-devel] " Johannes Berg
2006-05-17 21:41           ` Benjamin Herrenschmidt
2006-05-17 21:41           ` [Alsa-devel] " Benjamin Herrenschmidt
2006-05-17 12:17   ` Johannes Berg
2006-05-17 12:37     ` Takashi Iwai
2006-05-17 12:37     ` [Alsa-devel] " Takashi Iwai
2006-05-17 12:17   ` Johannes Berg
2006-05-16 12:27 ` Takashi Iwai
2006-05-16 12:31 ` Jaroslav Kysela
2006-05-16 12:31   ` [Alsa-devel] " Jaroslav Kysela
2006-05-16 22:04   ` Benjamin Herrenschmidt
2006-05-16 22:04   ` [Alsa-devel] " Benjamin Herrenschmidt
2006-05-17  6:41     ` Jaroslav Kysela
2006-05-17  6:41       ` [Alsa-devel] " Jaroslav Kysela
2006-05-17 12:21       ` Johannes Berg
2006-05-17 12:21       ` Johannes Berg
2006-05-17  9:47     ` [Alsa-devel] " Takashi Iwai
2006-05-17 12:24       ` Johannes Berg
2006-05-17 12:24       ` Johannes Berg
2006-05-17  9:47     ` Takashi Iwai
2006-05-16 14:53 ` Lee Revell
2006-05-16 14:53   ` [Alsa-devel] " Lee Revell
2006-05-16 14:55   ` Johannes Berg
2006-05-16 14:55   ` [Alsa-devel] " Johannes Berg
2006-05-17 15:38     ` Wolfgang Pfeiffer
2006-05-17 15:38     ` Wolfgang Pfeiffer
2006-05-16 22:00 ` Benjamin Herrenschmidt
2006-05-16 22:04   ` [Alsa-devel] " Lee Revell
2006-05-16 22:04   ` Lee Revell
2006-05-16 22:00 ` Benjamin Herrenschmidt
  -- strict thread matches above, loose matches on Subject: below --
2006-05-16 12:02 Johannes Berg

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=1147817023.6753.5.camel@localhost.localdomain \
    --to=benh@kernel.crashing.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=benjamin@sipsolutions.net \
    --cc=johannes@sipsolutions.net \
    --cc=linuxppc-dev@ozlabs.org \
    --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.