On Mon, 11.01.10 18:33, Henrique de Moraes Holschuh (hmh@xxxxxxxxxx) wrote: > > 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). Hmm, for the PA case at least we can ignore the PC speaker/firmware beeps. I have no plans to ever support them, so for all that matters to me they do not exist, I won't show them in the UI and I will happily ignore that part of the routing topology. > 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... So you are suggesting that the integral volume steps translate to different amplification factors depending on the path taken? Oh man, that sucks. This cannot be modelled in the current ALSA mixer API, as every slider element has exactly one, fixed, dB range attached to it. (or are you suggesting they only change by a constant factor? If so, we could probably just ignore that constant factor at least for the PA case since ALSA does not define what the reference level for the dB value it exports actually is. Could be max amp, could be some "standard" voltage, or whatever) Hmm, and the AGC is problematic indeed. I'd probably ignore it for the modelling though under the assumption that for low volume streams it doesn't matter too much. > 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). These kind of deviations in the paths really suck. ALSA has no API for topology information, so we cannot discover this routing "abnormaly" and can base the paths we control only on assumptions. But we generally do not assume that the mute of an element like this would cover headphones but not the docking station output. And fixing that requires device-specific quirks. And I hate those. > > 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. PA does support multiple mixer paths from which you can select exactly one. We do not try to cover every possibility the hw provides, i.e. output to multiple ports we generally don't try to cover unless it is an obvious option. We want to cover common desktop cases mostly. As mentioned ALSA currently has no interface at all to query the topology of the audio routing. Some folks (especially the embedded people) have been discussing this on and off for some time, but noone ever wrote any code AFAIK. Theres also the question which application could actually make use of this information. PA probably would, but it would reduce the full tree by quite a bit since I am not interested in a big part of the routing, i.e. regarding analog CD playback, PC speaker stuff, wavetable audio and so on. And are there any other apps? Also, another question is whether it is even possible to get that information for all cards, especially USB cards which might abstract that away (?). So, yes, the situation sucks a bit. The paths PA currently uses are mostly based on assumptions how most desktop cards work and which element controls what and in which order solely based on the names of the controls, and a few special purpose path sets for very specific cards. That's all there is. > 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. Not sure whether there is an API to figure out whether a PCI card is onboard or not. > > 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: Yes, we do support multiple paths, but it is the user's job to pick one (as long as jack sensing with ALSA is unsettled business as it is right now) > 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). If we have that information we can merge volume sliders. i.e. currently it's kinda confusing to control the volume on those older thinkpads since the software volume controls change a diffrerent volume control than the hw buttons. And in software there traditionally even was PCM and master which both could influence the volume. So, for a non-guru user is was generally pretty hard to figure out why his machine doesn't produce a single beep, since it could be a whole series of sliders that could be at fault. So in PA we nowadays take all sliders of the path and synthesize a single big one out of it. If a user select a specific volume we apply it first to the "outermost" element, and what that element lacks in range or granularity we then apply to the next innermost and so on, and then finally what's left we apply in sw. See http://pulseaudio.org/wiki/PulseAudioStoleMyVolumes for more information. All this is very much useful for the desktop case only, since we ignore non PCM audio and suchlike. > 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... Yepp, I thought about that too. If PA doesn't know they are dependant and for some reason they appear in the same path PA could get very confused. But then again, they should normally not show up in the same path. And unless ther might be a bug lurking somewhere PA should be able to suppress external volume change events that are triggered by itself, regardless of the exact way they were triggered. > Assuming there is a good answer to issue (1), is there a way to fix > (2)? I think (2) is not a problem for PA -- and if should turn out be a problem for PA it should be an easy fix I am happy to make. Not sure if other apps might get confused though. Takashi, what do you say regarding the idea of having interdependant volume sliders like this? > > 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 Of course, what I measured was the headphone out connected to the mic in. I did not measure the speakers or the ultrabase port. > > > 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. At least PA shifts all scales in a way that 0dB becomes max amplification anyway (and then we show one special point on the volume scale we call "base" which is where the low-level alsa sliders are all at what alsa calls 0dB under the assumption that this might be the loudest point with minimal distortion or some other level that is useful as a reference level). Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ------------------------------------------------------------------------------ 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
