Re: thinkpad_acpi alsa sub-driver with 2.6.33-rc3-git2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 11 Jan 2010, Lennart Poettering wrote:
> The problem is that we now have two seperate ALSA cards that control the 
> volume of the same audio stream. There is currently no way for userspace 

Nah, you have two separate ALSA cards that control the volume of a NUMBER of
audio streams, like this:

[AC97/HDA]----*-----(1.1dB)---(?)--- dock line-out
              *
 fw beep---[mixer]->-+---(variable amp 1)---(AGC)--- speakers
                     +          |
                     +---(variable amp 2)---(?)-- headphones
                                |
 EVR----------------------------|


Where the EVR (electronic volume) for the two variable amplifiers are tied
together to the same reference, which is generated by the ACPI EC.

There are three paths in that mess, and their contents are not the same (the
speakers and headphones have an additional signal added, the one used to
generate firmware beeps.  I *think* it is the legacy PC squeaker crap,
because ALSA HDA digital beeps break it (silencing firmware alarms and
feedback, btw. Not Nice).

AFAIK, there are extra static-gain circuits in those paths that are
different in different thinkpad models.  That is the reason why I didn't
bother with dB information.

Oh, and there is an AGC in the speaker path, which will reduce gain if it
thinks there will be any sort of clipping... so it is outright impossible to
know what gain is being seen by the speakers.

http://www.datasheetcatalog.org/datasheet/panasonic/SDC00047AEB.pdf

The headphone path has at max 6dB gain (ignoring any further amplification,
which could exist).  The speaker path has at max 17dB gain (again, ignoring
any extra amplification that might exist).  It is an EVR amplifier, after
all...

Note that the mixer (including MUTE) doesn't affect line out, and in fact,
the firmware beeps are NOT available in the line-out output either (I tested
this on my T43).

> to discover this and handle this situation properly. IIRC there was a 
> very brief discussion about this problem with Takashi (added to CC) 
> somewhere some years ago, and I think he suggested that the proper way 
> to support this is to merge the sound card mixer and the laptop mixer in 
> some way, so that the laptop volume slider just appears as yet another 
> slider in the sound card mixer. The question is where to do that: on the 
> kernel side or in userspace. Takashi, what do you say?

Look at the audio topology... Can we provide any sort of sane representation
for that?  There are three branching paths with different properties.

That said, if ALSA gives me a good control hotplug interface that can be
used to add/remove controls to a second card, irrespective of which module
initializes first (could be either), then I will consider using it.  I would
have to be able to tell if a card is the main embedded device in the
motherboard as well (AC97 or HDA), as oposed to, say, an USB or PCI sound
card, as the controls must be attached to the main embedded device, only.

> A while back, when Matthew Garrett (added to CC) started to work on 
> doing this thinkpad/ALSA integration work I sat down and measured the dB 
> attenuation factors of the X60s mixer in the hope this could be exported 
> by the ALSA driver, for the integral volume steps. With this information 
> provided by the driver and the merging of the mixers in place it would 
> be very easy for PA to make use of this information by means of 

The single audio path model looks useless on thinkpads.  I will assume PA
can deal with branching audio paths.  Still, there are two issues:

1. What is the point of providing dB information if measuring the speaker
output is outright impossible (due to the AGC), and the values for the other
paths are different for different thinkpad models, so it would have to be
whitelist based anyway and we would only have a few models measured (it is
_NOT_ easy to measure extra-noisy crap like the embedded audio in a
thinkpad).

2. ALSA can handle part of the above audio path model easily (because it
simply doesn't *care*), as long as I export *two* mixer controls with
different dB properties.  But AFAIK it does not export the information that
the two are interdependent, so PA won't know it, and AFAIK I can't export
the information about line-out at all...

Assuming there is a good answer to issue (1), is there a way to fix (2)?

> The tool I made my dB measurements with is available here:
> 
> http://git.0pointer.de/?p=dbmeasure.git
> 
> The README:
> 
> http://git.0pointer.de/?p=dbmeasure.git;a=blob;f=README
> 
> Here's an excerpt from that mail I sent to Matthew last year which 
> includes the dB values for the X60s:

Yeah.  Didn't work that great in my T43 because it is really _noisy_, but I
got the numbers out of it after accepting a much higher noise floor.  They
didn't seem to match the X60s, but I will hunt them down in my T43 again and
double-check now that I have a human-readable table of dB values from the
X60s to compare to :P

> > What confused me a bit though is that the thinkpad-acpi claims the
> > volume could set be in the range 0-15 (see
> > /proc/acpi/ibm/volume). Which would suggest that there are 16 possible
> > levels. However, there are only 15 I can control via the keys and the
> > driver limits them to 15 too when I try to set the via sw. I am
> > assuming now that that file is simply inaccurate or the programmer who
> > did that was just confused...

Yeah, I have fixed that very recently.

> > This puts 0dB at 14, i.e. maximum amplification.

Hmm, but there is a *real* amplifier pipeline in there, it is not 0dB.  In
fact, it has a really bad THD if you have it anywhere near level 14, because
the amplifier is _not_ anything to write home about.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
ibm-acpi-devel mailing list
ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

[Index of Archives]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Photo]     [Yosemite Photos]     [Yosemite Advice]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux