[alsa-devel] Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII
Heya,
a while back I wrote a little tool "dbmeasure" which can be used to determine dB attenuation data for alsa mixer controls. I have now extended this little dB tools suite to include a tiny tool "dbverify" that can be used to verify the correctness of existing dB data exposed by the drivers. It should be relatively easy to use that tool, suitable even for non-guru folks who want to debug the dB information from alsa.
http://git.0pointer.de/?p=dbmeasure.git git://git.0pointer.de/dbmeasure.git
Just run "make" in a git checkout and then try:
$ ./dbverify Aureon51MkII Master 30 200
That will verify the dB data of the "Master" control of the sound card that goes by the id "Aureon51MkII". It will compare the discrete volume steps 30 and 200: first it will play a full amplitude sine wave at mixer volume step 30, and then will change to mixer volume step 200, but attenuate the sine wave in software compensating for the volume change. So once you hear the sine wave attenuated by the hw, and once by the software. If the card's dB data is correct both sines should have the same volume.
Now, playing around with this, I could verify what I already mentioned to Jarsolav elsewhere earlier: it seems that particularly USB cards seem to expose invalid dB data (at least all mine do). For example, for the above mentioned Aureon 5.1 it's really *way* off -- if you posess that card just run the line above, and listen to the difference. It's really bad. OTOH the dB data of the HDA cards I own is pretty accurate as it seems, at least I was unable to decide just by listening which sine wave was attenuated by sw, and which by hw.
Getting back to the invalid dB data from the USB cards: the question is whether the USB descriptor data is badly parsed, and the dB mismatch hence systematic for USB cards, or if these cards are just crappy and include invalid data? In which case I wonder what we could do about that? The Aureon's dB range already looks suspicous, since both the max and the min dB value are < 0 (-47.69 to -1.97), so maybe we could add some heuristics to filter out data that already looks suspicous?
Invalid dB data from the driver is a real problem for the "flat volume" logic in PA. We basically allow each app to control the full hw volume range individually, and then set the hw volume to the max of what all apps wanted and attenuate the other streams accordingly. On the Aureon this doesn't work at all, since the attenuation of the streams is miscalculated due to the invalid dB data.
Lennart
Lennart Poettering wrote:
Getting back to the invalid dB data from the USB cards: the question is whether the USB descriptor data is badly parsed, and the dB mismatch hence systematic for USB cards,
USB descriptors use units of 1/256th dB, while ALSA uses 1/100th dB. When the level is computed from the minimum plus a multiple of the step size, rounding errors add up considerately.
ALSA 1.0.21 (kernel 2.6.32) added a different TLV type that reports the range with the min/max values to minimize those rounding errors.
Regards, Clemens
On Tue, 16 Feb 2010, Clemens Ladisch wrote:
Lennart Poettering wrote:
Getting back to the invalid dB data from the USB cards: the question is whether the USB descriptor data is badly parsed, and the dB mismatch hence systematic for USB cards,
USB descriptors use units of 1/256th dB, while ALSA uses 1/100th dB. When the level is computed from the minimum plus a multiple of the step size, rounding errors add up considerately.
ALSA 1.0.21 (kernel 2.6.32) added a different TLV type that reports the range with the min/max values to minimize those rounding errors.
Unfortunately, it's not the case of a rounding problem. The USB specification is too much vague and vendors don't use the dB range correctly. For example, I tested SB MP3+ USB device and reported ranges were:
Master: -47.87dB..0.06dB # correct Line: 0dB..47.81dB # seems correct -47.81dB..0dB Line Capture: -0.18dB..23.81dB # seems correct -17.81dB..6.18dB
I just did tests using another soundcard to generate sounds and played back the captured result to determine the gain in the capture direction.
I put my results to:
http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=c3a3e040f01457...
The SB MP3+ uses AC97 codec AD1995 with some own ASIC from Creative. So I think that even the 47.87 values are not correct and the real ranges are from -48dB..0dB and -18dB..6dB.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
On Tue, 16.02.10 09:24, Jaroslav Kysela (perex@perex.cz) wrote:
ALSA 1.0.21 (kernel 2.6.32) added a different TLV type that reports the range with the min/max values to minimize those rounding errors.
Unfortunately, it's not the case of a rounding problem. The USB specification is too much vague and vendors don't use the dB range correctly. For example, I tested SB MP3+ USB device and reported ranges were:
Master: -47.87dB..0.06dB # correct Line: 0dB..47.81dB # seems correct -47.81dB..0dB Line Capture: -0.18dB..23.81dB # seems correct -17.81dB..6.18dB
Hmm, how did you choose where to put 0dB?
http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=c3a3e040f01457...
The SB MP3+ uses AC97 codec AD1995 with some own ASIC from Creative. So I think that even the 47.87 values are not correct and the real ranges are from -48dB..0dB and -18dB..6dB.
So if I understand this correctly, then the way to handle issues like this is to measure the dB data for each USB card in question and then update the drivers with quirks accordingly?
So if I want my Aureon to work properly I better start measuring now?
Would it be feasible to allow overriding of the dB data from userspace, i.e. from the alsa mixer init db perhaps?
Lennart
On Tue, Feb 16, 2010 at 03:32:01PM +0100, Lennart Poettering wrote:
On Tue, 16.02.10 09:24, Jaroslav Kysela (perex@perex.cz) wrote:
Line: 0dB..47.81dB # seems correct -47.81dB..0dB Line Capture: -0.18dB..23.81dB # seems correct -17.81dB..6.18dB
Hmm, how did you choose where to put 0dB?
The Line one looks like someone got attenuation and gain confused, which is a fairly common mistake for people to make when copying information from one place to another. Possibly a similar thing going on with the Line Capture control, plus a fixed 6dB gain (which may well be a separate amp...).
On Tue, 16.02.10 14:40, Mark Brown (broonie@opensource.wolfsonmicro.com) wrote:
On Tue, Feb 16, 2010 at 03:32:01PM +0100, Lennart Poettering wrote:
On Tue, 16.02.10 09:24, Jaroslav Kysela (perex@perex.cz) wrote:
Line: 0dB..47.81dB # seems correct -47.81dB..0dB Line Capture: -0.18dB..23.81dB # seems correct -17.81dB..6.18dB
Hmm, how did you choose where to put 0dB?
The Line one looks like someone got attenuation and gain confused, which is a fairly common mistake for people to make when copying information from one place to another. Possibly a similar thing going on with the Line Capture control, plus a fixed 6dB gain (which may well be a separate amp...).
I remember that a while back we had a discussion on alsa-devel regarding the fact that ALSA does not define relative to what the dB values reported by the mixer elements actually are measured. Some mixer controls export dB values relative to max amplification (e.g. my integrated USB speakers here), others relative to the output of some other mixer element, and others relative to different standard or not-so-standard output voltages. And there is no API to figure out what the base is.
Now, what Jaroslav listed above suggests that he chose carefully where he put 0dB. I was just wondering about that. Jaroslav, how did you choose where to put 0dB?
Lennart
On Tue, Feb 16, 2010 at 04:40:16PM +0100, Lennart Poettering wrote:
Now, what Jaroslav listed above suggests that he chose carefully where he put 0dB. I was just wondering about that. Jaroslav, how did you choose where to put 0dB?
FWIW all the drivers I do take whatever the datasheet says the gain/attenuation range is for the control in question. For most modern embedded CODECs there will be multiple user controllable gains in the path.
We really need to get an API for exposing path information to userspace to fully describe what's going on here.
On Tue, 16 Feb 2010, Lennart Poettering wrote:
On Tue, 16.02.10 14:40, Mark Brown (broonie@opensource.wolfsonmicro.com) wrote:
On Tue, Feb 16, 2010 at 03:32:01PM +0100, Lennart Poettering wrote:
On Tue, 16.02.10 09:24, Jaroslav Kysela (perex@perex.cz) wrote:
Line: 0dB..47.81dB # seems correct -47.81dB..0dB Line Capture: -0.18dB..23.81dB # seems correct -17.81dB..6.18dB
Hmm, how did you choose where to put 0dB?
The Line one looks like someone got attenuation and gain confused, which is a fairly common mistake for people to make when copying information from one place to another. Possibly a similar thing going on with the Line Capture control, plus a fixed 6dB gain (which may well be a separate amp...).
I remember that a while back we had a discussion on alsa-devel regarding the fact that ALSA does not define relative to what the dB values reported by the mixer elements actually are measured. Some mixer controls export dB values relative to max amplification (e.g. my integrated USB speakers here), others relative to the output of some other mixer element, and others relative to different standard or not-so-standard output voltages. And there is no API to figure out what the base is.
Now, what Jaroslav listed above suggests that he chose carefully where he put 0dB. I was just wondering about that. Jaroslav, how did you choose where to put 0dB?
Basically, if I remember correctly the discussion, 0dB on all elements should main unchanged volume, <0dB attenuation and >0dB gain. We cannot measure precisely other components on path like analog volume wheels (like SB MP3+ has to change line-out volume), analog amplifiers and other analog signal modificators.
So, if you use one headphones and speakers with defined and fixed volume settings, you can measure differences for the card with broken dB volume ranges. I just used another HDA card in notebook with 0dB settings on all playback controls on path, captured stream from this card on my USB card and played this stream back on my USB card watching and relating the volume levels according dB values. It's not 100% correct, but at least it's something to start with.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
On Tue, 16.02.10 17:29, Jaroslav Kysela (perex@perex.cz) wrote:
I remember that a while back we had a discussion on alsa-devel regarding the fact that ALSA does not define relative to what the dB values reported by the mixer elements actually are measured. Some mixer controls export dB values relative to max amplification (e.g. my integrated USB speakers here), others relative to the output of some other mixer element, and others relative to different standard or not-so-standard output voltages. And there is no API to figure out what the base is.
Now, what Jaroslav listed above suggests that he chose carefully where he put 0dB. I was just wondering about that. Jaroslav, how did you choose where to put 0dB?
Basically, if I remember correctly the discussion, 0dB on all elements should main unchanged volume, <0dB attenuation and >0dB gain.
But you need some kind of "anchor" for that. What you write above applies only for elements that have some kind of analog input and output. But the most interesting components are probably the DAC and ADC (i.e. the "innermost" elements), and it's not clear what level they output, so the "anchor" for the relative dB values is missing...
So, if you use one headphones and speakers with defined and fixed volume settings, you can measure differences for the card with broken dB volume ranges. I just used another HDA card in notebook with 0dB settings on all playback controls on path, captured stream from this card on my USB card and played this stream back on my USB card watching and relating the volume levels according dB values. It's not 100% correct, but at least it's something to start with.
Hmm, so you basically tuned the USB card's DAC/ADC level to the HDA card's DAC/ADC.
I now measured the "Master" slider of my aureon (USB 0ccd:0028, TerraTec Aureon 5.1 MkII) with the aforementioned dbmeasure tool and a loopback cable. The aureon has 65536 volume steps, but I was too lazy to measure them all. So I only measured every 3000th. From the max volume to the min volume:
65536 0 dB 62536 0.00560039 dB 59536 0.00694678 dB 56536 0.00616732 dB 53536 0.00645077 dB 50536 0.00673421 dB 47536 -1.49514 dB 44536 -1.49455 dB 41536 -1.49648 dB 38536 -2.98666 dB 35536 -2.98486 dB 32536 -2.98536 dB 29536 -4.48688 dB 26536 -6.00084 dB 23536 -5.99928 dB 20536 -9.00246 dB 17536 -10.5425 dB 14536 -16.5274 dB 11536 -32.9435 dB 8536 -43.4326 dB 5536 -43.5066 dB 2536 -43.2968 dB 0 -43.4431 dB
If you plot this it looks as if the card actually only implements 10 or so discrete steps, and at around 10000 just becomes a constant function.
ALSA reports -47.87 .. -1.97 for this. So it seems the overall range the USB data reports is not really that far off, but the volume function in bteween is.
The noise level of these measurements is < -58 dB.
What's the next step with this measurement data? Will you take it from here, or shall I provide you with more data?
Lennart
On Tue, Feb 16, 2010 at 10:07:03PM +0100, Lennart Poettering wrote:
On Tue, 16.02.10 17:29, Jaroslav Kysela (perex@perex.cz) wrote:
Basically, if I remember correctly the discussion, 0dB on all elements should main unchanged volume, <0dB attenuation and >0dB gain.
But you need some kind of "anchor" for that. What you write above applies only for elements that have some kind of analog input and output. But the most interesting components are probably the DAC and ADC (i.e. the "innermost" elements), and it's not clear what level they output, so the "anchor" for the relative dB values is missing...
Typically the DACs and ADCs will have a full scale signal at line reference level - it should generally be a good approximation with nothing else to go on.
If you plot this it looks as if the card actually only implements 10 or so discrete steps, and at around 10000 just becomes a constant function.
That's quite common.
On Tue, 16.02.10 22:39, Mark Brown (broonie@opensource.wolfsonmicro.com) wrote:
On Tue, Feb 16, 2010 at 10:07:03PM +0100, Lennart Poettering wrote:
On Tue, 16.02.10 17:29, Jaroslav Kysela (perex@perex.cz) wrote:
Basically, if I remember correctly the discussion, 0dB on all elements should main unchanged volume, <0dB attenuation and >0dB gain.
But you need some kind of "anchor" for that. What you write above applies only for elements that have some kind of analog input and output. But the most interesting components are probably the DAC and ADC (i.e. the "innermost" elements), and it's not clear what level they output, so the "anchor" for the relative dB values is missing...
Typically the DACs and ADCs will have a full scale signal at line reference level - it should generally be a good approximation with nothing else to go on.
"line reference level"? What is that?
Lennart
On Tue, Feb 16, 2010 at 11:42:12PM +0100, Lennart Poettering wrote:
On Tue, 16.02.10 22:39, Mark Brown (broonie@opensource.wolfsonmicro.com) wrote:
Typically the DACs and ADCs will have a full scale signal at line reference level - it should generally be a good approximation with nothing else to go on.
"line reference level"? What is that?
As I understand it (and bear in mind that I'm a software rather than electrical engineer) it's not 100% fixed, though since the actual result depends very much on what it's connected to an absolute answer isn't as important as it might be. 1V RMS is very standard in consumer stuff at least.
If you could frame exactly the information that you're looking for then I should be able to ask a few people who are electrical engineers and get a more coherent answer for you. I guess you're looking at trying to have PulseAudio set sensible levels by default?
On Tue, 16.02.10 23:38, Mark Brown (broonie@opensource.wolfsonmicro.com) wrote:
On Tue, Feb 16, 2010 at 11:42:12PM +0100, Lennart Poettering wrote:
On Tue, 16.02.10 22:39, Mark Brown (broonie@opensource.wolfsonmicro.com) wrote:
Typically the DACs and ADCs will have a full scale signal at line reference level - it should generally be a good approximation with nothing else to go on.
"line reference level"? What is that?
As I understand it (and bear in mind that I'm a software rather than electrical engineer) it's not 100% fixed, though since the actual result depends very much on what it's connected to an absolute answer isn't as important as it might be. 1V RMS is very standard in consumer stuff at least.
If you could frame exactly the information that you're looking for then I should be able to ask a few people who are electrical engineers and get a more coherent answer for you. I guess you're looking at trying to have PulseAudio set sensible levels by default?
Nah. I actually don't need this value for PulseAudio. In PulseAudio I chose to shift all scales so that maximum amplification becomes 0 dB, so that the UIs are similar to how most hifi racks do it, and which I think is a nice, easy and understandable logic. That way my volume scales range from -inf dB to 0 dB in all cases, regardless of the hardware/drivers in use. Of course, that means that ALSA's own 0dB is not directly visible on the scale. Because it might be sometimes useful to know where it is, we export that position as "base volume" and the UIs show it with a little marker at the side.
The reason I was asking how Jaroslav chose the 0dB position for his measurements was purely because I wanted to do my own measurements for that Aureon card. The dbmeasure tool I wrote for stuff like that puts 0dB at max amplification, however Jaroslav didn't, so I was wondering how he chose 0dB then.
Lennart
On Wed, Feb 17, 2010 at 12:56:58AM +0100, Lennart Poettering wrote:
Nah. I actually don't need this value for PulseAudio. In PulseAudio I chose to shift all scales so that maximum amplification becomes 0 dB, so that the UIs are similar to how most hifi racks do it, and which I
Interesting. The hifi equipment I've dealt with typically doesn't present any units at all in the UI outside of level monitors.
think is a nice, easy and understandable logic. That way my volume scales range from -inf dB to 0 dB in all cases, regardless of the hardware/drivers in use. Of course, that means that ALSA's own 0dB is not directly visible on the scale. Because it might be sometimes useful to know where it is, we export that position as "base volume" and the UIs show it with a little marker at the side.
Yeah, the actual zero point is definitely needed - it gives an indication of the expected output level which is very useful during setup.
I really do need to find time to dig into this code at some point - there's also the digital vs. analogue gain thing I've mentioned to you before that I wanted to look at.
On Wed, 17.02.10 11:17, Mark Brown (broonie@opensource.wolfsonmicro.com) wrote:
On Wed, Feb 17, 2010 at 12:56:58AM +0100, Lennart Poettering wrote:
Nah. I actually don't need this value for PulseAudio. In PulseAudio I chose to shift all scales so that maximum amplification becomes 0 dB, so that the UIs are similar to how most hifi racks do it, and which I
Interesting. The hifi equipment I've dealt with typically doesn't present any units at all in the UI outside of level monitors.
My old Yamaha hifi rack had a volume dial where the max was labeled 0 dB and the min setting was -inf dB. My new Yamaha shows the dB level on an LCD screen whever you touch the volume dial, and it too goes from -inf dB to 0 dB. I kinda assumed that stereos from other manufacturers would do the exact same thing, but tbh never checked.
Lennart
On 02/17/2010 02:01 PM, Lennart Poettering wrote:
On Wed, 17.02.10 11:17, Mark Brown (broonie@opensource.wolfsonmicro.com) wrote:
On Wed, Feb 17, 2010 at 12:56:58AM +0100, Lennart Poettering wrote:
Nah. I actually don't need this value for PulseAudio. In PulseAudio I chose to shift all scales so that maximum amplification becomes 0 dB, so that the UIs are similar to how most hifi racks do it, and which I
Interesting. The hifi equipment I've dealt with typically doesn't present any units at all in the UI outside of level monitors.
My old Yamaha hifi rack had a volume dial where the max was labeled 0 dB and the min setting was -inf dB. My new Yamaha shows the dB level on an LCD screen whever you touch the volume dial, and it too goes from -inf dB to 0 dB. I kinda assumed that stereos from other manufacturers would do the exact same thing, but tbh never checked.
At least some of them do it differently: http://en.wikipedia.org/wiki/Up_to_eleven
/Mads
On 16 February 2010 23:56, Lennart Poettering mznyfn@0pointer.de wrote:
The reason I was asking how Jaroslav chose the 0dB position for his measurements was purely because I wanted to do my own measurements for that Aureon card. The dbmeasure tool I wrote for stuff like that puts 0dB at max amplification, however Jaroslav didn't, so I was wondering how he chose 0dB then.
Lennart
I think the digital side is clear. So I will not go into that.
I think we need to separate the analogue side into a number of categories: 1) Standard consumer line-out levels. 2) Standard pro line-out levels. 3) Consumer line-in levels. 4) Pro line-in levels. 5) Consumer mic levels. 6) Pro mic levels. 7) Consumer speaker levels. 8) Pro speaker levels.
On the analogue side, I believe the 0dB gain point is intended to be the point at which one can be fairly sure that the distortion will be low for a sensible full scale input. I think we can get better definition on items 1 to 4. To this end, I think ALSA needs a new control type so the user can set what line out voltages will occur using standard full scale digital inputs. http://en.wikipedia.org/wiki/Decibel
On Wed, Feb 17, 2010 at 11:55:17AM +0000, James Courtier-Dutton wrote:
On 16 February 2010 23:56, Lennart Poettering mznyfn@0pointer.de wrote:
The reason I was asking how Jaroslav chose the 0dB position for his measurements was purely because I wanted to do my own measurements for that Aureon card. The dbmeasure tool I wrote for stuff like that puts 0dB at max amplification, however Jaroslav didn't, so I was wondering how he chose 0dB then.
Lennart
I think the digital side is clear. So I will not go into that.
I think we need to separate the analogue side into a number of categories:
- Standard consumer line-out levels.
- Standard pro line-out levels.
- Consumer line-in levels.
- Pro line-in levels.
- Consumer mic levels.
- Pro mic levels.
- Consumer speaker levels.
- Pro speaker levels.
There's also headphones there, though for both speakers and headphones it's questionable if we want to do anything.
On the analogue side, I believe the 0dB gain point is intended to be the point at which one can be fairly sure that the distortion will be low for a sensible full scale input.
Generally 0dB is pass through (which does also tend to be the optimal performance point). Actual expected gain levels will vary depending on application - for example, a microphone input will usually need an amplifier with fairly high gain in the path to get the signal to a level usable by the rest of the system.
2010/2/17 James Courtier-Dutton james.dutton@gmail.com
On 16 February 2010 23:56, Lennart Poettering mznyfn@0pointer.de wrote:
The reason I was asking how Jaroslav chose the 0dB position for his measurements was purely because I wanted to do my own measurements for that Aureon card. The dbmeasure tool I wrote for stuff like that puts 0dB at max amplification, however Jaroslav didn't, so I was wondering how he chose 0dB then.
Lennart
I think the digital side is clear. So I will not go into that.
The problem is at the digital side , The range between -inf dB and -48dB / -96dB software atten is lost during the conversion of the floating format format to S16_LE or S32_LE ( native format supported by hardware driver )
i.e. the bottom part of the pulseaudio volume control cannot be used
2010/2/17 Lennart Poettering mznyfn@0pointer.de
On Tue, 16.02.10 23:38, Mark Brown (broonie@opensource.wolfsonmicro.com) wrote:
On Tue, Feb 16, 2010 at 11:42:12PM +0100, Lennart Poettering wrote:
On Tue, 16.02.10 22:39, Mark Brown (
broonie@opensource.wolfsonmicro.com) wrote:
Typically the DACs and ADCs will have a full scale signal at line reference level - it should generally be a good approximation with nothing else to go on.
"line reference level"? What is that?
As I understand it (and bear in mind that I'm a software rather than electrical engineer) it's not 100% fixed, though since the actual result depends very much on what it's connected to an absolute answer isn't as important as it might be. 1V RMS is very standard in consumer stuff at least.
If you could frame exactly the information that you're looking for then I should be able to ask a few people who are electrical engineers and get a more coherent answer for you. I guess you're looking at trying to have PulseAudio set sensible levels by default?
Nah. I actually don't need this value for PulseAudio. In PulseAudio I chose to shift all scales so that maximum amplification becomes 0 dB, so that the UIs are similar to how most hifi racks do it, and which I think is a nice, easy and understandable logic. That way my volume scales range from -inf dB to 0 dB in all cases, regardless of the hardware/drivers in use. Of course, that means that ALSA's own 0dB is not directly visible on the scale. Because it might be sometimes useful to know where it is, we export that position as "base volume" and the UIs show it with a little marker at the side.
The reason I was asking how Jaroslav chose the 0dB position for his measurements was purely because I wanted to do my own measurements for that Aureon card. The dbmeasure tool I wrote for stuff like that puts 0dB at max amplification, however Jaroslav didn't, so I was wondering how he chose 0dB then.
Lennart
From the viewpoint of user, they only care how easy to find the point which
is no software gain or software auttentation since software gain lead to clipping
On Thu, 18.02.10 09:48, Raymond Yau (superquad.vortex2@gmail.com) wrote:
From the viewpoint of user, they only care how easy to find the point which is no software gain or software auttentation since software gain lead to clipping
We decided to expose software amplification in the UI, since it is actually a much requested feature, and I have used myself a couple of times.
The primary use case is when you play a DVD (which very often has audio normalized to a very low volume) on weak speakers, such as laptop speakers.
Lennart
2010/2/18 Lennart Poettering mznyfn@0pointer.de
On Thu, 18.02.10 09:48, Raymond Yau (superquad.vortex2@gmail.com) wrote:
From the viewpoint of user, they only care how easy to find the point
which
is no software gain or software auttentation since software gain lead to clipping
We decided to expose software amplification in the UI, since it is actually a much requested feature, and I have used myself a couple of times.
The primary use case is when you play a DVD (which very often has audio normalized to a very low volume) on weak speakers, such as laptop speakers.
Lennart
VLC media player has a slider from 0% to 300% , so the user are easily to know 100% is the point which there is no software gain and no software autentation
How did PA expose these software amplication in the UI so that ordinary user can know that point ?
For the Mic Boost +20dB case , how PA handle this +20dB switch in the "Flat Volume" model if you did not expost the Mic Boost switch to the user in the mixer control ?
+20dB is quite significant in with the Capture Volume control
On 18 February 2010 06:15, Raymond Yau superquad.vortex2@gmail.com wrote:
VLC media player has a slider from 0% to 300% , so the user are easily to know  100% is the point which there is no software gain and no software autentation
I would have thought that VLC should have used dB for the gain. In that case 100% == 0dB. What would 50% be? -6dB ? As sound volumes are not linear, they are exponential, the dB logarithmic scale is the best one to use.
The 0dB point is fairly easy for a user to understand. I find it easier to understand that %
On Thu, 18.02.10 14:15, Raymond Yau (superquad.vortex2@gmail.com) wrote:
VLC media player has a slider from 0% to 300% , so the user are easily to know 100% is the point which there is no software gain and no software autentation
How did PA expose these software amplication in the UI so that ordinary user can know that point ?
Depends on the UI program. gnome-volume-control currently only puts a marker at the ALSA 0dB point, but not a second one where software amp starts.
However, I have been talking to a couple of folks regarding presenting that in a nicer way, i.e. colour slider ranges green/yellow/red:
http://pulseaudio.org/wiki/WritingVolumeControlUIs#Colouredvolumesliders
Summary: green → all hw vol control where alsa reports < 0dB; yellow → hw control where alsa reports > 0dB; and finally red → software volume control.
I think this color coding of the slider ranges is the best once can do to represent the technical background of all of this in a way that gives the right indication even for people with no technical background.
For the Mic Boost +20dB case , how PA handle this +20dB switch in the "Flat Volume" model if you did not expost the Mic Boost switch to the user in the mixer control ?
+20dB is quite significant in with the Capture Volume control
We currently don't cover boost switches, simply because tehre is no dB data queriable for them.
I'd really prefer if those boost switches would be turned into binary volume elements which carry normal dB information like any other volume element. After all they are just a volume element, with only two steps.
Lennart
On Thu, 18 Feb 2010, Lennart Poettering wrote:
For the Mic Boost +20dB case , how PA handle this +20dB switch in the "Flat Volume" model if you did not expost the Mic Boost switch to the user in the mixer control ?
+20dB is quite significant in with the Capture Volume control
We currently don't cover boost switches, simply because tehre is no dB data queriable for them.
I'd really prefer if those boost switches would be turned into binary volume elements which carry normal dB information like any other volume element. After all they are just a volume element, with only two steps.
I like this idea.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
On Fri, Feb 19, 2010 at 09:17:01AM +0100, Jaroslav Kysela wrote:
On Thu, 18 Feb 2010, Lennart Poettering wrote:
I'd really prefer if those boost switches would be turned into binary volume elements which carry normal dB information like any other volume element. After all they are just a volume element, with only two steps.
I like this idea.
Me too, in fact I've already been doing it for drivers I've been working on.
2010/2/19 Jaroslav Kysela perex@perex.cz
On Thu, 18 Feb 2010, Lennart Poettering wrote:
For the Mic Boost +20dB case , how PA handle this +20dB switch in the
"Flat
Volume" model if you did not expost the Mic Boost switch to the user in
the
mixer control ?
+20dB is quite significant in with the Capture Volume control
We currently don't cover boost switches, simply because tehre is no dB data queriable for them.
I'd really prefer if those boost switches would be turned into binary volume elements which carry normal dB information like any other volume element. After all they are just a volume element, with only two steps.
I like this idea.
Jaroslav
PA assume every sound card can only record from one capture source at the same time (like those AC97 card )
However HDA support multi streaming capture , the capture device 0 may have more than one subdevice "Capture sources" depend on the codec and device 2 has 2 subdevice for capturing "Input sources" on some codec
Is HDA_SUBDEV_NID_FLAG or any API for the application to find the correct mixer control for these kind of capturing subdevices ? ( simple mixer api is not able to know the subdevice number )
On Fri, 19.02.10 18:57, Raymond Yau (superquad.vortex2@gmail.com) wrote:
PA assume every sound card can only record from one capture source at the same time (like those AC97 card )
That is true. PA does not try to cover the complete functionality of the hardware. We limit ourselves to what we think is common on the desktop or in a mobile environment, and I don't think recording from mic and line-in at the same time would be useful in more than exceptional cases.
Is HDA_SUBDEV_NID_FLAG or any API for the application to find the correct mixer control for these kind of capturing subdevices ? ( simple mixer api is not able to know the subdevice number )
There is currently no API at all to figure out the relation between PCM devices and mixer controls in ALSA. PA hences bases this all on assumptions and expectes in this acse that the first mixer control is also the first PCM device, if you understand what I mean by that.
Lennart
2010/2/19 Lennart Poettering mznyfn@0pointer.de
On Fri, 19.02.10 18:57, Raymond Yau (superquad.vortex2@gmail.com) wrote:
PA assume every sound card can only record from one capture source at the same time (like those AC97 card )
That is true. PA does not try to cover the complete functionality of the hardware. We limit ourselves to what we think is common on the desktop or in a mobile environment, and I don't think recording from mic and line-in at the same time would be useful in more than exceptional cases.
http://www.intel.com/design/chipsets/hdaudio.htm
The most common onboard audio is HDA so this is not any exceptional cases
Those HDA multi streaming feature are most users wanted in desktop enviornment, are pulseaudio really designed for deskop or just only for notebook and mobile ?
The front panel green/pink jack can be used by one application while the rear panel audio jacks can be used to another application for surround or mic for karaoke
*When AC‘97 was initially developed*, users were typically listening to only music and movies with stereo sound. With the success of DVD movies encoded with Dolby* Digital and DTS* multi-channel audio formats, users have become accustomed to listening in full surround sound with anywhere from six to eight speakers. While AC‘97 technology has struggled to keep pace with all these advancements, Intel High Definition Audio is designed specifically for the high-quality multi-channel audio experiences. Newer audio and video encoding/decoding algorithms also enable a higher-quality listening experience.
*Consumers also want the ability to play back two different audio tracks*, such as a CD and a DVD simultaneously, which can't be done using current audio solutions. Intel HD Audio features multi-streaming capabilities that give users the ability to send two or more different audio streams to different locations at the same time, from the same PC.
Send a game's sound through 5.1 speakers while the Internet chatting audio is sent through your headset.
Send a DVD movie with 5.1 audio to a surround sound system in the living room, while you listen to digital music and surf the Web on the PC.
Is HDA_SUBDEV_NID_FLAG or any API for the application to find the correct mixer control for these kind of capturing subdevices ? ( simple mixer
api
is not able to know the subdevice number )
There is currently no API at all to figure out the relation between PCM devices and mixer controls in ALSA. PA hences bases this all on assumptions and expectes in this acse that the first mixer control is also the first PCM device, if you understand what I mean by that.
Lennart
THe point is that PA release/close the device (suspend on idle) , if another application using the subdevice 0 before PA resume/reopen, PA will open subdevice 1 and cannot find the correct capture volume control and user will complain they cannot record
Since PA did not check the subdevice number to find the correct mixer control
On Sun, 21.02.10 11:49, Raymond Yau (superquad.vortex2@gmail.com) wrote:
The most common onboard audio is HDA so this is not any exceptional cases
Those HDA multi streaming feature are most users wanted in desktop enviornment, are pulseaudio really designed for deskop or just only for notebook and mobile ?
The front panel green/pink jack can be used by one application while the rear panel audio jacks can be used to another application for surround or mic for karaoke
I am not entirely convinced that this is really a common case.
But anyway, there is nothing in PA that would limit it to not use multiple parallel devices of a sound card at the same time, with the exception that ALSA currently has no enumeration API which could inform us which uses of the card are exclusive each other and which ones are not. PA currently tries to open the sound card in all combinations possible, assuming that EBUSY means it found an invalid combination. If one day ALSA gains an API that allows figuring out which combinations of streams are possible and which ones are not, I am happy to reinvestigate the whole issue.
Send a game's sound through 5.1 speakers while the Internet chatting audio is sent through your headset.
More often than not you'd probably use two seperate cards for that.
Send a DVD movie with 5.1 audio to a surround sound system in the living room, while you listen to digital music and surf the Web on the PC.
I somehow doubt that this is the most common of use cases we need to care about.
THe point is that PA release/close the device (suspend on idle) , if another application using the subdevice 0 before PA resume/reopen, PA will open subdevice 1 and cannot find the correct capture volume control and user will complain they cannot record
Since PA did not check the subdevice number to find the correct mixer control
I'd certainly check the subdevice id if the smixer API would supply me with it.
Lennart
2010/2/22 Lennart Poettering mznyfn@0pointer.de
On Sun, 21.02.10 11:49, Raymond Yau (superquad.vortex2@gmail.com) wrote:
The most common onboard audio is HDA so this is not any exceptional cases
Those HDA multi streaming feature are most users wanted in desktop enviornment, are pulseaudio really designed for deskop or just only for notebook and mobile ?
The front panel green/pink jack can be used by one application while the rear panel audio jacks can be used to another application for surround or mic for karaoke
I am not entirely convinced that this is really a common case.
VT17xx codec already support independent HP mode
http://git.alsa-project.org/?p=alsa-kernel.git;a=commit;h=cdc1784d49258198df...
**** List of PLAYBACK Hardware Devices ****
card 0: SB [HDA ATI SB], device 0: VT1708S Analog [VT1708S Analog] Subdevices: 1/2 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 card 0: SB [HDA ATI SB], device 1: VT1708S Digital [VT1708S Digital] Subdevices: 1/1 Subdevice #0: subdevice #0
**** List of CAPTURE Hardware Devices **** card 0: SB [HDA ATI SB], device 0: VT1708S Analog [VT1708S Analog] Subdevices: 2/2 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1
AD1988B 10 channels codec on my ASUS P5BV already has 3 capture subdevices
**** List of CAPTURE Hardware Devices **** card 0: Intel [HDA Intel], device 0: AD198x Analog [AD198x Analog] Subdevices: 3/3 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 Subdevice #2: subdevice #2 card 0: Intel [HDA Intel], device 1: AD198x Digital [AD198x Digital] Subdevices: 1/1 Subdevice #0: subdevice #0
http://www.analog.com/en/audiovideo-products/audio-codecs/ad1988b/products/p...
The AD1988A and AD1988B have 10 DACs and 6 ADCs, Analog mixer supports recording and playback of signals from multiple sources
ALC88x
**** List of CAPTURE Hardware Devices **** card 0: VT82xx [HDA VIA VT82xx], device 0: ALC888 Analog [ALC888 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: VT82xx [HDA VIA VT82xx], device 2: ALC888 Analog [ALC888 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0
Do any PA developer has a desktop computer with HDA audio ?
But anyway, there is nothing in PA that would limit it to not use multiple parallel devices of a sound card at the same time, with the exception that ALSA currently has no enumeration API which could inform us which uses of the card are exclusive each other and which ones are not. PA currently tries to open the sound card in all combinations possible, assuming that EBUSY means it found an invalid combination. If one day ALSA gains an API that allows figuring out which combinations of streams are possible and which ones are not, I am happy to reinvestigate the whole issue.
Send a game's sound through 5.1 speakers while the Internet chatting
audio
is sent through your headset.
More often than not you'd probably use two seperate cards for that.
Send a DVD movie with 5.1 audio to a surround sound system in the living room, while you listen to digital music and surf the Web on the PC.
I somehow doubt that this is the most common of use cases we need to care about.
THe point is that PA release/close the device (suspend on idle) , if
another
application using the subdevice 0 before PA resume/reopen, PA will open subdevice 1 and cannot find the correct capture volume control and user
will
complain they cannot record
Since PA did not check the subdevice number to find the correct mixer control
I'd certainly check the subdevice id if the smixer API would supply me with it.
if ( snd_pcm_info_get_subdevices_count(pcm_info) > 1 ) && ( snd_pcm_info_get_subdevices_count(pcm_info) < 8 ))
snd_mixer_selem_id_set_index(sid, snd_pcm_info_get_subdevice(pcm_info));
Lennart
On Tue, 23.02.10 12:47, Raymond Yau (superquad.vortex2@gmail.com) wrote:
The most common onboard audio is HDA so this is not any exceptional cases
Those HDA multi streaming feature are most users wanted in desktop enviornment, are pulseaudio really designed for deskop or just only for notebook and mobile ?
The front panel green/pink jack can be used by one application while the rear panel audio jacks can be used to another application for surround or mic for karaoke
I am not entirely convinced that this is really a common case.
Uh, I wanted to say "use case" here...
Do any PA developer has a desktop computer with HDA audio ?
I certainly do. But the fact that this is not the most common use case and the ALSA API is not really up to the task yet to query the full routing table I am not sure supporting parallel and independant streaming support for heapdphones and speakers should be a priority for PA.
if ( snd_pcm_info_get_subdevices_count(pcm_info) > 1 ) && ( snd_pcm_info_get_subdevices_count(pcm_info) < 8 ))
snd_mixer_selem_id_set_index(sid, snd_pcm_info_get_subdevice(pcm_info));
Are you suggesting that on all drivers the the index part of a snd_mixer_selem_id_t directly relates to the subdevice id of a PCM stream on the same card? Is that true? Jaroslav, Clemens, Takashi, can you say something about that?
(tbh I find that very unlikely, given that the device index would not be encoded then)
Lennart
2010/2/24 Lennart Poettering mznyfn@0pointer.de
On Tue, 23.02.10 12:47, Raymond Yau (superquad.vortex2@gmail.com) wrote:
The most common onboard audio is HDA so this is not any exceptional
cases
Those HDA multi streaming feature are most users wanted in desktop enviornment, are pulseaudio really designed for deskop or just only
for
notebook and mobile ?
The front panel green/pink jack can be used by one application while
the
rear panel audio jacks can be used to another application for
surround or
mic for karaoke
I am not entirely convinced that this is really a common case.
Uh, I wanted to say "use case" here...
Do any PA developer has a desktop computer with HDA audio ?
I certainly do. But the fact that this is not the most common use case and the ALSA API is not really up to the task yet to query the full routing table I am not sure supporting parallel and independant streaming support for heapdphones and speakers should be a priority for PA.
if ( snd_pcm_info_get_subdevices_count(pcm_info) > 1 ) && ( snd_pcm_info_get_subdevices_count(pcm_info) < 8 ))
snd_mixer_selem_id_set_index(sid, snd_pcm_info_get_subdevice(pcm_info));
Are you suggesting that on all drivers the the index part of a snd_mixer_selem_id_t directly relates to the subdevice id of a PCM stream on the same card? Is that true? Jaroslav, Clemens, Takashi, can you say something about that?
(tbh I find that very unlikely, given that the device index would not be encoded then)
Lennart
This is only true for those Capture controls for HDA since only HDA support multi streaming
The reason of using ( snd_pcm_info_get_subdevices_ count(pcm_info) < 8 ) is au88x0 have at least 8 capture subdevices which capture from one source from AC97 codec
2010/2/24 Lennart Poettering mznyfn@0pointer.de
On Tue, 23.02.10 12:47, Raymond Yau (superquad.vortex2@gmail.com) wrote:
Are you suggesting that on all drivers the the index part of a snd_mixer_selem_id_t directly relates to the subdevice id of a PCM stream on the same card? Is that true? Jaroslav, Clemens, Takashi, can you say something about that?
(tbh I find that very unlikely, given that the device index would not be encoded then)
Lennart
Those are the per voice volume control of the hardware mixing sound card
This is a little bit different from the pulse pre-application volume control .
It seem that pulseaudio allow the application open only one audio stream , but this per voice volume control allow application to open more than one audio stream
e.g. Skype need to play the human voice and the ringing bell and it have to open two audio streams using either two hw devices or dmix
2010/2/22 Lennart Poettering mznyfn@0pointer.de
On Sun, 21.02.10 11:49, Raymond Yau (superquad.vortex2@gmail.com) wrote:
The most common onboard audio is HDA so this is not any exceptional cases
Those HDA multi streaming feature are most users wanted in desktop enviornment, are pulseaudio really designed for deskop or just only for notebook and mobile ?
The front panel green/pink jack can be used by one application while the rear panel audio jacks can be used to another application for surround or mic for karaoke
I am not entirely convinced that this is really a common case.
But anyway, there is nothing in PA that would limit it to not use multiple parallel devices of a sound card at the same time, with the exception that ALSA currently has no enumeration API which could inform us which uses of the card are exclusive each other and which ones are not. PA currently tries to open the sound card in all combinations possible, assuming that EBUSY means it found an invalid combination.
if ( snd_pcm_info_get_subdevices_count(pcm_info) > 1 ) mean you can open the device more than one time since the device has more than 1 subdevice
2010/2/22 Lennart Poettering mznyfn@0pointer.de
On Sun, 21.02.10 11:49, Raymond Yau (superquad.vortex2@gmail.com) wrote:
The most common onboard audio is HDA so this is not any exceptional cases
Those HDA multi streaming feature are most users wanted in desktop enviornment, are pulseaudio really designed for deskop or just only for notebook and mobile ?
The front panel green/pink jack can be used by one application while the rear panel audio jacks can be used to another application for surround or mic for karaoke
Send a game's sound through 5.1 speakers while the Internet chatting
audio
is sent through your headset.
More often than not you'd probably use two seperate cards for that.
why do you need another sound card when you onboard audio HDA already support this feature ?
e.g. Skype can use alsa hw device for better latency lhttp://mailman.alsa-project.org/mailman/listinfo/alsa-devel
2010/2/19 Lennart Poettering mznyfn@0pointer.de
Is HDA_SUBDEV_NID_FLAG or any API for the application to find the correct mixer control for these kind of capturing subdevices ? ( simple mixer
api
is not able to know the subdevice number )
There is currently no API at all to figure out the relation between PCM devices and mixer controls in ALSA. PA hences bases this all on assumptions and expectes in this acse that the first mixer control is also the first PCM device, if you understand what I mean by that.
Lennart
No, there is API which allow PA to find out the correct mixer control
However Simple Mixer API cannot know the subdevice number , you have to use control API ( the lower level API used by Simple Mixer API )
On Sun, 21.02.10 12:01, Raymond Yau (superquad.vortex2@gmail.com) wrote:
However Simple Mixer API cannot know the subdevice number , you have to use control API ( the lower level API used by Simple Mixer API )
Unfortunately there is no way from the simple mixer to the lower level mixer. And we certainly want to make use of the abstraction that smixer is...
It would be great if the smixer would include some API that gives me a hint to which device/subdevice a specific snd_mixer_elem_t belongs to.
Lennart
Lennart Poettering wrote:
On Sun, 21.02.10 12:01, Raymond Yau (superquad.vortex2@gmail.com) wrote:
However Simple Mixer API cannot know the subdevice number , you have to use control API ( the lower level API used by Simple Mixer API )
Unfortunately there is no way from the simple mixer to the lower level mixer.
_From the check_unplugged function in alsa-utils/alsamixer/mixer_widget.c:
err = snd_mixer_get_hctl(mixer, mixer_device_name, &hctl); if (err >= 0) ctl = snd_hctl_ctl(hctl);
It would be great if the smixer would include some API that gives me a hint to which device/subdevice a specific snd_mixer_elem_t belongs to.
Often, there is no 1:1 correspondence between mixer elements and PCM devices. Only mixer controls with interface PCM (not MIXER) have (sub-) device numbers, and at the moment this is used only for controls that are associated with the streams of hardware-mixing-capable cards.
Getting information about the mixer layout (like the nodes reported by HDA and USB devices) is on the TODO list; the only reason it isn't being implemented is lack of time.
Regards, Clemens
2010/2/23 Clemens Ladisch clemens@ladisch.de
Lennart Poettering wrote:
On Sun, 21.02.10 12:01, Raymond Yau (superquad.vortex2@gmail.com) wrote:
However Simple Mixer API cannot know the subdevice number , you have to
use
control API ( the lower level API used by Simple Mixer API )
Unfortunately there is no way from the simple mixer to the lower level mixer.
From the check_unplugged function in alsa-utils/alsamixer/mixer_widget.c:
err = snd_mixer_get_hctl(mixer, mixer_device_name, &hctl); if (err >= 0) ctl = snd_hctl_ctl(hctl);It would be great if the smixer would include some API that gives me a hint to which device/subdevice a specific snd_mixer_elem_t belongs to.
Often, there is no 1:1 correspondence between mixer elements and PCM devices. Only mixer controls with interface PCM (not MIXER) have (sub-) device numbers, and at the moment this is used only for controls that are associated with the streams of hardware-mixing-capable cards.
Getting information about the mixer layout (like the nodes reported by HDA and USB devices) is on the TODO list; the only reason it isn't being implemented is lack of time.
Regards, Clemens
for hda , Since PA server open pcm device , so it still can use
snd_mixer_selem_id_set_index(sid, snd_pcm_info_get_subdevice(pcm_info));
pavucontrol still can query PA server to get the sudevice numer whenever PA resum from suspend
But gnome volume control has no way to know which application open which subdevice
On Tue, 23.02.10 11:08, Clemens Ladisch (clemens@ladisch.de) wrote:
Lennart Poettering wrote:
On Sun, 21.02.10 12:01, Raymond Yau (superquad.vortex2@gmail.com) wrote:
However Simple Mixer API cannot know the subdevice number , you have to use control API ( the lower level API used by Simple Mixer API )
Unfortunately there is no way from the simple mixer to the lower level mixer.
From the check_unplugged function in alsa-utils/alsamixer/mixer_widget.c:
err = snd_mixer_get_hctl(mixer, mixer_device_name, &hctl); if (err >= 0) ctl = snd_hctl_ctl(hctl);
But that still doesn't give me a hint which snd_ctl_eleme_t belongs to which snd_mixer_eleme_t, does it?
It would be great if the smixer would include some API that gives me a hint to which device/subdevice a specific snd_mixer_elem_t belongs to.
Often, there is no 1:1 correspondence between mixer elements and PCM devices. Only mixer controls with interface PCM (not MIXER) have (sub-) device numbers, and at the moment this is used only for controls that are associated with the streams of hardware-mixing-capable cards.
Which are not that many, right? Not HDA at least?
Getting information about the mixer layout (like the nodes reported by HDA and USB devices) is on the TODO list; the only reason it isn't being implemented is lack of time.
Would be great to have that.
Lennart
2010/2/24 Lennart Poettering mznyfn@0pointer.de
On Tue, 23.02.10 11:08, Clemens Ladisch (clemens@ladisch.de) wrote:
Lennart Poettering wrote:
On Sun, 21.02.10 12:01, Raymond Yau (superquad.vortex2@gmail.com)
wrote:
However Simple Mixer API cannot know the subdevice number , you have
to use
control API ( the lower level API used by Simple Mixer API )
Unfortunately there is no way from the simple mixer to the lower level mixer.
It would be great if the smixer would include some API that gives me a hint to which device/subdevice a specific snd_mixer_elem_t belongs to.
Often, there is no 1:1 correspondence between mixer elements and PCM devices. Only mixer controls with interface PCM (not MIXER) have (sub-) device numbers, and at the moment this is used only for controls that are associated with the streams of hardware-mixing-capable cards.
Which are not that many, right? Not HDA at least?
Card hw:1 'Intel'/'HDA Intel at 0xff9f4000 irq 22' Mixer name : 'Analog Devices AD1988' Components : 'HDA:11d41988' Controls : 48 Simple ctrls : 26
Simple mixer control 'Capture',0 Capabilities: cvolume cswitch Capture channels: Front Left - Front Right Limits: Capture 0 - 54 Front Left: Capture 39 [72%] [0.00dB] [off] Front Right: Capture 39 [72%] [0.00dB] [off] Simple mixer control 'Capture',1 Capabilities: cvolume cswitch Capture channels: Front Left - Front Right Limits: Capture 0 - 54 Front Left: Capture 39 [72%] [0.00dB] [off] Front Right: Capture 39 [72%] [0.00dB] [off] Simple mixer control 'Capture',2 Capabilities: cvolume cswitch Capture channels: Front Left - Front Right Limits: Capture 0 - 54 Front Left: Capture 39 [72%] [0.00dB] [off] Front Right: Capture 39 [72%] [0.00dB] [off]
Simple mixer control 'Input Source',0 Capabilities: cenum Items: 'Front Mic' 'Line' 'Mic' 'CD' 'Mix' Item0: 'Mic' Simple mixer control 'Input Source',1 Capabilities: cenum Items: 'Front Mic' 'Line' 'Mic' 'CD' 'Mix' Item0: 'Front Mic' Simple mixer control 'Input Source',2 Capabilities: cenum Items: 'Front Mic' 'Line' 'Mic' 'CD' 'Mix' Item0: 'Front Mic'
control.28 { comment.access 'read write' comment.type BOOLEAN comment.count 2 iface MIXER name 'Capture Switch' value.0 false value.1 false } control.29 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 54' comment.dbmin -5850 comment.dbmax 2250 iface MIXER name 'Capture Volume' index 1 value.0 39 value.1 39 } control.30 { comment.access 'read write' comment.type BOOLEAN comment.count 2 iface MIXER name 'Capture Switch' index 1 value.0 false value.1 false } control.31 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 54' comment.dbmin -5850 comment.dbmax 2250 iface MIXER name 'Capture Volume' index 2 value.0 39 value.1 39 } control.32 { comment.access 'read write' comment.type BOOLEAN comment.count 2 iface MIXER name 'Capture Switch' index 2 value.0 false value.1 false } control.33 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 'Front Mic' comment.item.1 Line comment.item.2 Mic comment.item.3 CD comment.item.4 Mix iface MIXER name 'Input Source' value Mic } control.34 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 'Front Mic' comment.item.1 Line comment.item.2 Mic comment.item.3 CD comment.item.4 Mix iface MIXER name 'Input Source' index 1 value 'Front Mic' } control.35 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 'Front Mic' comment.item.1 Line comment.item.2 Mic comment.item.3 CD comment.item.4 Mix iface MIXER name 'Input Source' index 2 value 'Front Mic' }
Getting information about the mixer layout (like the nodes reported by HDA and USB devices) is on the TODO list; the only reason it isn't being implemented is lack of time.
Would be great to have that.
Lennart
Lennart Poettering wrote:
On Tue, 23.02.10 11:08, Clemens Ladisch (clemens@ladisch.de) wrote:
Lennart Poettering wrote:
Unfortunately there is no way from the simple mixer to the lower level mixer.
From the check_unplugged function in alsa-utils/alsamixer/mixer_widget.c:
err = snd_mixer_get_hctl(mixer, mixer_device_name, &hctl); if (err >= 0) ctl = snd_hctl_ctl(hctl);
But that still doesn't give me a hint which snd_ctl_eleme_t belongs to which snd_mixer_eleme_t, does it?
Not really; the point of the simple mixer interface is to abstract away some of the ctl naming conventions.
It would be great if the smixer would include some API that gives me a hint to which device/subdevice a specific snd_mixer_elem_t belongs to.
Often, there is no 1:1 correspondence between mixer elements and PCM devices. Only mixer controls with interface PCM (not MIXER) have (sub-) device numbers, and at the moment this is used only for controls that are associated with the streams of hardware-mixing-capable cards.
Which are not that many, right? Not HDA at least?
No, most recent hardware was designed for software mixing. Only the snd-emu10k1, snd-via82xx and snd-ymfpci drivers implement such controls.
Regards, Clemens
2010/2/24 Clemens Ladisch clemens@ladisch.de
Lennart Poettering wrote:
On Tue, 23.02.10 11:08, Clemens Ladisch (clemens@ladisch.de) wrote:
Lennart Poettering wrote:
Unfortunately there is no way from the simple mixer to the lower
level
mixer.
From the check_unplugged function in
alsa-utils/alsamixer/mixer_widget.c:
err = snd_mixer_get_hctl(mixer, mixer_device_name, &hctl); if (err >= 0) ctl = snd_hctl_ctl(hctl);But that still doesn't give me a hint which snd_ctl_eleme_t belongs to which snd_mixer_eleme_t, does it?
Not really; the point of the simple mixer interface is to abstract away some of the ctl naming conventions.
It would be great if the smixer would include some API that gives me
a
hint to which device/subdevice a specific snd_mixer_elem_t belongs
to.
Often, there is no 1:1 correspondence between mixer elements and PCM devices. Only mixer controls with interface PCM (not MIXER) have
(sub-)
device numbers, and at the moment this is used only for controls that are associated with the streams of hardware-mixing-capable cards.
Which are not that many, right? Not HDA at least?
No, most recent hardware was designed for software mixing. Only the snd-emu10k1, snd-via82xx and snd-ymfpci drivers implement such controls.
Regards, Clemens
The current implementation of HDA capturing subdevices are almost as same as those playback subdevices of hardware mixing sound card
each subdevice support the same format , rate , channels , the number of input sources are also the same
The only difference is the type IFACE_MIXER and IFACE_PCM since using IFACE_PCM will break most mixer application
2010/2/24 Clemens Ladisch clemens@ladisch.de
Lennart Poettering wrote:
On Tue, 23.02.10 11:08, Clemens Ladisch (clemens@ladisch.de) wrote:
Lennart Poettering wrote:
Unfortunately there is no way from the simple mixer to the lower
level
mixer.
From the check_unplugged function in
alsa-utils/alsamixer/mixer_widget.c:
err = snd_mixer_get_hctl(mixer, mixer_device_name, &hctl); if (err >= 0) ctl = snd_hctl_ctl(hctl);But that still doesn't give me a hint which snd_ctl_eleme_t belongs to which snd_mixer_eleme_t, does it?
Not really; the point of the simple mixer interface is to abstract away some of the ctl naming conventions.
It would be great if the smixer would include some API that gives me
a
hint to which device/subdevice a specific snd_mixer_elem_t belongs
to.
Often, there is no 1:1 correspondence between mixer elements and PCM devices. Only mixer controls with interface PCM (not MIXER) have
(sub-)
device numbers, and at the moment this is used only for controls that are associated with the streams of hardware-mixing-capable cards.
Which are not that many, right? Not HDA at least?
No, most recent hardware was designed for software mixing. Only the snd-emu10k1, snd-via82xx and snd-ymfpci drivers implement such controls.
Regards, Clemens
However the playback subdevices of some HDA codec did not support the same range of channels
(e.g. vt1708s has two playback subdevices ,
if independent HP mode is ON , one subdevice can only suppport 2 channels and the other subdevices support 2 ,4 ,6
if independent HP mode is OFF , the subdevice may support 2, 4, 6 and 8 channels
2010/2/23 Clemens Ladisch clemens@ladisch.de
Lennart Poettering wrote:
On Sun, 21.02.10 12:01, Raymond Yau (superquad.vortex2@gmail.com) wrote:
However Simple Mixer API cannot know the subdevice number , you have to
use
control API ( the lower level API used by Simple Mixer API )
Unfortunately there is no way from the simple mixer to the lower level mixer.
Often, there is no 1:1 correspondence between mixer elements and PCM devices. Only mixer controls with interface PCM (not MIXER) have (sub-) device numbers, and at the moment this is used only for controls that are associated with the streams of hardware-mixing-capable cards.
But there is really 1:1 correspondence for HDA capture sudevices and the control related to capturing
card 1: Intel [HDA Intel], device 0: AD198x Analog [AD198x Analog] Subdevices: 3/3 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 Subdevice #2: subdevice #2
Card hw:1 'Intel'/'HDA Intel at 0xff9f4000 irq 22' Mixer name : 'Analog Devices AD1988' Components : 'HDA:11d41988' Controls : 48 Simple ctrls : 26
Simple mixer control 'Capture',0 Capabilities: cvolume cswitch Capture channels: Front Left - Front Right Limits: Capture 0 - 54 Front Left: Capture 39 [72%] [0.00dB] [off] Front Right: Capture 39 [72%] [0.00dB] [off] Simple mixer control 'Capture',1 Capabilities: cvolume cswitch Capture channels: Front Left - Front Right Limits: Capture 0 - 54 Front Left: Capture 39 [72%] [0.00dB] [off] Front Right: Capture 39 [72%] [0.00dB] [off] Simple mixer control 'Capture',2 Capabilities: cvolume cswitch Capture channels: Front Left - Front Right Limits: Capture 0 - 54 Front Left: Capture 39 [72%] [0.00dB] [off] Front Right: Capture 39 [72%] [0.00dB] [off]
Simple mixer control 'Input Source',0 Capabilities: cenum Items: 'Front Mic' 'Line' 'Mic' 'CD' 'Mix' Item0: 'Mic' Simple mixer control 'Input Source',1 Capabilities: cenum Items: 'Front Mic' 'Line' 'Mic' 'CD' 'Mix' Item0: 'Front Mic' Simple mixer control 'Input Source',2 Capabilities: cenum Items: 'Front Mic' 'Line' 'Mic' 'CD' 'Mix' Item0: 'Front Mic'
control.28 { comment.access 'read write' comment.type BOOLEAN comment.count 2 iface MIXER name 'Capture Switch' value.0 false value.1 false } control.29 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 54' comment.dbmin -5850 comment.dbmax 2250 iface MIXER name 'Capture Volume' index 1 value.0 39 value.1 39 } control.30 { comment.access 'read write' comment.type BOOLEAN comment.count 2 iface MIXER name 'Capture Switch' index 1 value.0 false value.1 false } control.31 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 54' comment.dbmin -5850 comment.dbmax 2250 iface MIXER name 'Capture Volume' index 2 value.0 39 value.1 39 } control.32 { comment.access 'read write' comment.type BOOLEAN comment.count 2 iface MIXER name 'Capture Switch' index 2 value.0 false value.1 false } control.33 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 'Front Mic' comment.item.1 Line comment.item.2 Mic comment.item.3 CD comment.item.4 Mix iface MIXER name 'Input Source' value Mic } control.34 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 'Front Mic' comment.item.1 Line comment.item.2 Mic comment.item.3 CD comment.item.4 Mix iface MIXER name 'Input Source' index 1 value 'Front Mic' } control.35 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 'Front Mic' comment.item.1 Line comment.item.2 Mic comment.item.3 CD comment.item.4 Mix iface MIXER name 'Input Source' index 2 value 'Front Mic' }
Getting information about the mixer layout (like the nodes reported by HDA and USB devices) is on the TODO list; the only reason it isn't being implemented is lack of time.
Regards, Clemens
2010/2/23 Clemens Ladisch clemens@ladisch.de
Lennart Poettering wrote:
Only mixer controls with interface PCM (not MIXER) have (sub-) device numbers, and at the moment this is used only for controls that are associated with the streams of hardware-mixing-capable cards.
Regards, Clemens
Just implementing those IFACE_PCM control for the driver is not enough for any practical use
Will need an API which allow the application to change the hardware per stream volume in optimized way by calling one api ? ( e.g. those API is need for if wine want to implement the real hardware acclerated dsound for those hardware mixing sound cards which support at least 16 voices )
On Fri, 19 Feb 2010, Raymond Yau wrote:
2010/2/19 Jaroslav Kysela perex@perex.cz
On Thu, 18 Feb 2010, Lennart Poettering wrote:
For the Mic Boost +20dB case , how PA handle this +20dB switch in the
"Flat
Volume" model if you did not expost the Mic Boost switch to the user in
the
mixer control ?
+20dB is quite significant in with the Capture Volume control
We currently don't cover boost switches, simply because tehre is no dB data queriable for them.
I'd really prefer if those boost switches would be turned into binary volume elements which carry normal dB information like any other volume element. After all they are just a volume element, with only two steps.
I like this idea.
JaroslavPA assume every sound card can only record from one capture source at the same time (like those AC97 card )
However HDA support multi streaming capture , the capture device 0 may have more than one subdevice "Capture sources" depend on the codec and device 2 has 2 subdevice for capturing "Input sources" on some codec
Is HDA_SUBDEV_NID_FLAG or any API for the application to find the correct mixer control for these kind of capturing subdevices ? ( simple mixer api is not able to know the subdevice number )
This API is not implemented at the time.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
2010/2/20 Jaroslav Kysela perex@perex.cz
On Fri, 19 Feb 2010, Raymond Yau wrote:
PA assume every sound card can only record from one capture source at
the same time (like those AC97 card )
However HDA support multi streaming capture , the capture device 0 may have more than one subdevice "Capture sources" depend on the codec and device 2 has 2 subdevice for capturing "Input sources" on some codec
Is HDA_SUBDEV_NID_FLAG or any API for the application to find the correct mixer control for these kind of capturing subdevices ? ( simple mixer api is not able to know the subdevice number )
This API is not implemented at the time.
Jaroslav
How did the current implementation of VIA Smart 5.1 and Independent HP mode affect alsa application such as pulseaudio ?
There are two playback subdevices and driver is supposed to support 5.1 smartly when the speaker jack is plugged
But PA developer seem expect an "2 4 6 channels switch" in all HDA codec
**** List of PLAYBACK Hardware Devices ****
card 0: NVidia [HDA NVidia], device 0: VT1708S Analog [VT1708S Analog] Subdevices: 2/2 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1
http://pulseaudio.org/ticket/743
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4895
seem bug in alsa driver for rear channels ?
On 19 February 2010 08:17, Jaroslav Kysela perex@perex.cz wrote:
On Thu, 18 Feb 2010, Lennart Poettering wrote:
For the Mic Boost +20dB case , how PA handle this +20dB switch in the "Flat Volume" model if you did not expost the Mic Boost switch to the user in the mixer control ?
+20dB is quite significant in with the Capture Volume control
We currently don't cover boost switches, simply because tehre is no dB data queriable for them.
I'd really prefer if those boost switches would be turned into binary volume elements which carry normal dB information like any other volume element. After all they are just a volume element, with only two steps.
I like this idea.
Seems like a good idea but what should we call it. If we already have a mic capture gain control, what shall we call the mic boost gain control so as not to confuse it with each other? Would keeping its current name be OK?
On Fri, 19.02.10 11:47, James Courtier-Dutton (james.dutton@gmail.com) wrote:
On 19 February 2010 08:17, Jaroslav Kysela perex@perex.cz wrote:
On Thu, 18 Feb 2010, Lennart Poettering wrote:
For the Mic Boost +20dB case , how PA handle this +20dB switch in the "Flat Volume" model if you did not expost the Mic Boost switch to the user in the mixer control ?
+20dB is quite significant in with the Capture Volume control
We currently don't cover boost switches, simply because tehre is no dB data queriable for them.
I'd really prefer if those boost switches would be turned into binary volume elements which carry normal dB information like any other volume element. After all they are just a volume element, with only two steps.
I like this idea.
Seems like a good idea but what should we call it. If we already have a mic capture gain control, what shall we call the mic boost gain control so as not to confuse it with each other? Would keeping its current name be OK?
Keeping the current names sounds reasonable to me.
Lennart
On Fri, 19 Feb 2010, James Courtier-Dutton wrote:
On 19 February 2010 08:17, Jaroslav Kysela perex@perex.cz wrote:
On Thu, 18 Feb 2010, Lennart Poettering wrote:
For the Mic Boost +20dB case , how PA handle this +20dB switch in the "Flat Volume" model if you did not expost the Mic Boost switch to the user in the mixer control ?
+20dB is quite significant in with the Capture Volume control
We currently don't cover boost switches, simply because tehre is no dB data queriable for them.
I'd really prefer if those boost switches would be turned into binary volume elements which carry normal dB information like any other volume element. After all they are just a volume element, with only two steps.
I like this idea.
Seems like a good idea but what should we call it. If we already have a mic capture gain control, what shall we call the mic boost gain control so as not to confuse it with each other? Would keeping its current name be OK?
I would keep the Boost suffix. It's easy to understand.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
2010/2/20 Jaroslav Kysela perex@perex.cz
On Fri, 19 Feb 2010, James Courtier-Dutton wrote:
On 19 February 2010 08:17, Jaroslav Kysela perex@perex.cz wrote:
On Thu, 18 Feb 2010, Lennart Poettering wrote:
For the Mic Boost +20dB case , how PA handle this +20dB switch in the
"Flat
Volume" model if you did not expost the Mic Boost switch to the user
in the
mixer control ?
+20dB is quite significant in with the Capture Volume control
We currently don't cover boost switches, simply because tehre is no dB data queriable for them.
I'd really prefer if those boost switches would be turned into binary volume elements which carry normal dB information like any other volume element. After all they are just a volume element, with only two steps.
I like this idea.
Seems like a good idea but what should we call it. If we already have a mic capture gain control, what shall we call the mic boost gain control so as not to confuse it with each other? Would keeping its current name be OK?
I would keep the Boost suffix. It's easy to understand.
Jaroslav
Some HDA codec has Front Mic Boost and Mic Boost and three sets of input sources
it is not easy to know the exact audio path
Card hw:1 'Intel'/'HDA Intel at 0xff9f4000 irq 22' Mixer name : 'Analog Devices AD1988' Components : 'HDA:11d41988' Controls : 48 Simple ctrls : 26
control.25 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 3' comment.dbmin 0 comment.dbmax 3000 iface MIXER name 'Front Mic Boost' value.0 0 value.1 0 } control.26 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 3' comment.dbmin 0 comment.dbmax 3000 iface MIXER name 'Mic Boost' value.0 0 value.1 0 }
control.27 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 54' comment.dbmin -5850 comment.dbmax 2250 iface MIXER name 'Capture Volume' value.0 39 value.1 39 } control.28 { comment.access 'read write' comment.type BOOLEAN comment.count 2 iface MIXER name 'Capture Switch' value.0 false value.1 false } control.29 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 54' comment.dbmin -5850 comment.dbmax 2250 iface MIXER name 'Capture Volume' index 1 value.0 39 value.1 39 } control.30 { comment.access 'read write' comment.type BOOLEAN comment.count 2 iface MIXER name 'Capture Switch' index 1 value.0 false value.1 false } control.31 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 54' comment.dbmin -5850 comment.dbmax 2250 iface MIXER name 'Capture Volume' index 2 value.0 39 value.1 39 } control.32 { comment.access 'read write' comment.type BOOLEAN comment.count 2 iface MIXER name 'Capture Switch' index 2 value.0 false value.1 false } control.33 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 'Front Mic' comment.item.1 Line comment.item.2 Mic comment.item.3 CD comment.item.4 Mix iface MIXER name 'Input Source' value Mic } control.34 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 'Front Mic' comment.item.1 Line comment.item.2 Mic comment.item.3 CD comment.item.4 Mix iface MIXER name 'Input Source' index 1 value 'Front Mic' } control.35 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 'Front Mic' comment.item.1 Line comment.item.2 Mic comment.item.3 CD comment.item.4 Mix iface MIXER name 'Input Source' index 2 value 'Front Mic' }
2010/2/19 Lennart Poettering mznyfn@0pointer.de
On Thu, 18.02.10 14:15, Raymond Yau (superquad.vortex2@gmail.com) wrote:
VLC media player has a slider from 0% to 300% , so the user are easily to know 100% is the point which there is no software gain and no software autentation
How did PA expose these software amplication in the UI so that ordinary
user
can know that point ?
Depends on the UI program. gnome-volume-control currently only puts a marker at the ALSA 0dB point, but not a second one where software amp starts.
For example , your program dbmeasure.c generate a full amplitude sine wave , the sine wave will be clipped for any software gain by pulseaudio , any hardware att. by DAC cannot change the clipped sine wave
2010/2/19 Lennart Poettering mznyfn@0pointer.de
On Thu, 18.02.10 14:15, Raymond Yau (superquad.vortex2@gmail.com) wrote:
However, I have been talking to a couple of folks regarding presenting that in a nicer way, i.e. colour slider ranges green/yellow/red:
http://pulseaudio.org/wiki/WritingVolumeControlUIs#Colouredvolumesliders
Summary: green → all hw vol control where alsa reports < 0dB; yellow → hw control where alsa reports > 0dB; and finally red → software volume control.
if Flat volumes are enabled on a per-sink basis and *PulseAudio* provides * per*-*application volume* controls only .
Neither pulse client nor alsa-pulse client can connect to PA server more than once. This mean that winepulse.drv have to perform mixing of 16 voices of dsound,
especially winepulse.drv did not provide midi or softsynth and still relies on wine-alsa to provide the midi support.
all those advantages of winepulse.drv (such as cross platform , software mixing ) are meaningless
2010/2/18 Lennart Poettering mznyfn@0pointer.de
On Thu, 18.02.10 09:48, Raymond Yau (superquad.vortex2@gmail.com) wrote:
From the viewpoint of user, they only care how easy to find the point
which
is no software gain or software auttentation since software gain lead to clipping
We decided to expose software amplification in the UI, since it is actually a much requested feature, and I have used myself a couple of times.
The primary use case is when you play a DVD (which very often has audio normalized to a very low volume) on weak speakers, such as laptop speakers.
Lennart
--
There are many mixer switch need to export to the mixer control
some are hardware specific and some are AC 97 standard feature which affect the dB volume
e.g. ac97 standard external amplifier
control.52 { comment.access 'read write' comment.type BOOLEAN comment.count 1 iface MIXER name 'External Amplifier' value true } }
and codec specifc
Sigmatel Surround Playback Volume which change the ratio of volume of "front" and "rear" channels
so the overall dB in the front speaker is also affected by this volume control
control.20 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 31' comment.dbmin -4650 comment.dbmax 0 iface MIXER name 'Sigmatel Surround Playback Volume' value.0 0 value.1 0
control.50 { comment.access 'read write' comment.type BOOLEAN comment.count 1 iface MIXER name 'Sigmatel 4-Speaker Stereo Playback Switch' value false }
control.49 { comment.access 'read write' comment.type BOOLEAN comment.count 1 iface MIXER name 'Sigmatel Output Bias Switch' value false }
control.51 { comment.access 'read write' comment.type BOOLEAN comment.count 1 iface MIXER name 'Sigmatel Surround Phase Inversion Playback ' value true }
2010/2/17 Lennart Poettering mznyfn@0pointer.de
Nah. I actually don't need this value for PulseAudio. In PulseAudio I chose to shift all scales so that maximum amplification becomes 0 dB, so that the UIs are similar to how most hifi racks do it, and which I think is a nice, easy and understandable logic. That way my volume scales range from -inf dB to 0 dB in all cases, regardless of the hardware/drivers in use. Of course, that means that ALSA's own 0dB is not directly visible on the scale. Because it might be sometimes useful to know where it is, we export that position as "base volume" and the UIs show it with a little marker at the side.
For AC97 Record gain registers 1ch
-inf dB to 22.5 dB
The default value is 0x8000 which is correspond to 0dB gain when mute on
Not sure your way of shifting all scales so that maximum amplification becomes 0 dB has any effect on the calculation since there is 22.5dB gain when you recording by all AC97 codec
The reason I was asking how Jaroslav chose the 0dB position for his measurements was purely because I wanted to do my own measurements for that Aureon card. The dbmeasure tool I wrote for stuff like that puts 0dB at max amplification, however Jaroslav didn't, so I was wondering how he chose 0dB then.
Lennart
--
2010/2/17 Lennart Poettering mznyfn@0pointer.de
On Tue, 16.02.10 23:38, Mark Brown (broonie@opensource.wolfsonmicro.com) wrote:
On Tue, Feb 16, 2010 at 11:42:12PM +0100, Lennart Poettering wrote:
On Tue, 16.02.10 22:39, Mark Brown (
broonie@opensource.wolfsonmicro.com) wrote:
Typically the DACs and ADCs will have a full scale signal at line reference level - it should generally be a good approximation with nothing else to go on.
"line reference level"? What is that?
As I understand it (and bear in mind that I'm a software rather than electrical engineer) it's not 100% fixed, though since the actual result depends very much on what it's connected to an absolute answer isn't as important as it might be. 1V RMS is very standard in consumer stuff at least.
If you could frame exactly the information that you're looking for then I should be able to ask a few people who are electrical engineers and get a more coherent answer for you. I guess you're looking at trying to have PulseAudio set sensible levels by default?
Nah. I actually don't need this value for PulseAudio. In PulseAudio I chose to shift all scales so that maximum amplification becomes 0 dB, so that the UIs are similar to how most hifi racks do it, and which I think is a nice, easy and understandable logic. That way my volume scales range from -inf dB to 0 dB in all cases, regardless of the hardware/drivers in use. Of course, that means that ALSA's own 0dB is not directly visible on the scale. Because it might be sometimes useful to know where it is, we export that position as "base volume" and the UIs show it with a little marker at the side.
The -inf dB is the level determined by the state of the mute switch.
The actual resolution of the codec depend on the number of step and the resolution of each step
But PA also did not provide dB information to alsa application through alsa-pulse plugin
amixer -D pulse Simple mixer control 'Master',0 Capabilities: pvolume pswitch pswitch-joined Playback channels: Front Left - Front Right Limits: Playback 0 - 65536 Mono: Front Left: Playback 65536 [100%] [on] Front Right: Playback 65536 [100%] [on]
Simple mixer control 'Capture',0 Capabilities: cvolume cswitch cswitch-joined
Capture channels: Front Left - Front Right Limits: Capture 0 - 65536 Front Left: Capture 65536 [100%] [on] Front Right: Capture 65536 [100%] [on]
Lennart Poettering wrote:
On Tue, 16.02.10 22:39, Mark Brown (broonie@opensource.wolfsonmicro.com) wrote:
On Tue, Feb 16, 2010 at 10:07:03PM +0100, Lennart Poettering wrote:
On Tue, 16.02.10 17:29, Jaroslav Kysela (perex@perex.cz) wrote:
Basically, if I remember correctly the discussion, 0dB on all elements should main unchanged volume, <0dB attenuation and >0dB gain.
But you need some kind of "anchor" for that. What you write above applies only for elements that have some kind of analog input and output. But the most interesting components are probably the DAC and ADC (i.e. the "innermost" elements), and it's not clear what level they output, so the "anchor" for the relative dB values is missing...
Typically the DACs and ADCs will have a full scale signal at line reference level - it should generally be a good approximation with nothing else to go on.
"line reference level"? What is that?
Lennart
There are two separate issues here. 1) Incorrect dB<->linear mapping ALSA Volume/Gain controls returning incorrect information about mapping from linear values to dB. E.g. adding "6dB" to the Volume controls while subtracting 6dB in software does not result in 0dB overall gain.
For volume controls the convention is 0dB == multiply by 1.0 == no change. Any sane digital volume control should obey this. For analog volumes, the 0dB position is entirely arbtrary, as I discuss below.
2) Absolute calibration of output levels. (This is *not* required to solve Lennart's problem) This would be required if you wanted two different (brands of) soundcard to output the same voltage for given source pcm.
_From the perspective of a Pro audio card maker, we have another kind of control at the analog terminals of the card. This is the Level control, and it specifies the absolute voltage at the output for full scale digital signal (and intermediate Volumes set to 0dB)
It has units of dBu http://en.wikipedia.org/wiki/Decibel#Voltage. (It might as well be dBV or any other reference dB measurement).
For our cards this is adjustable, but lets say for consumer cards it is fixed. This information is not currently available via the ALSA API.
A hypothetical example. [DAC>---[Variable gain>---[amplifier>---[output jack]
Lets say the DAC produces 2Vpp (6dBVpp) for fullscale digital input (0dBFS) and the amplifier has 6dB gain. and the variable gain is from -40dB to 0dB and the units of the reference level are dBVpp
Combining these we represent the DAC + gain + amplifier as a single Level control with units of dBVpp and range -28dBVpp to +12dBVpp
or equally valid, could represent it as a Volume with range -40dB to 0dB followed by a a fixed level of +12dBVpp
or equally valid, could represent it as a Volume with range 0dB to +40dB followed by a a fixed level of -28dBVpp
i.e. the 0dB position is arbitrary, related to what is chosen as the output reference level.
The fixed level information, would be attached to some representation of the output connector.
Clear as mud?
regards
Eliot Blennerhassett http://www.audioscience.com
On Wed, 17.02.10 12:47, Eliot Blennerhassett (linux@audioscience.com) wrote:
For our cards this is adjustable, but lets say for consumer cards it is fixed. This information is not currently available via the ALSA API.
I wonder how realistic it would even be to add an API for this. i.e. can we even know the refernce level? On many cards most likely not. For example, for my integrated USB speakers speaking of a reference voltage would already be misleading...
A hypothetical example. [DAC>---[Variable gain>---[amplifier>---[output jack]
Lets say the DAC produces 2Vpp (6dBVpp) for fullscale digital input (0dBFS) and the amplifier has 6dB gain. and the variable gain is from -40dB to 0dB and the units of the reference level are dBVpp
Combining these we represent the DAC + gain + amplifier as a single Level control with units of dBVpp and range -28dBVpp to +12dBVpp
or equally valid, could represent it as a Volume with range -40dB to 0dB followed by a a fixed level of +12dBVpp
or equally valid, could represent it as a Volume with range 0dB to +40dB followed by a a fixed level of -28dBVpp
i.e. the 0dB position is arbitrary, related to what is chosen as the output reference level.
Yepp, that's the exactly what I was asking, Jaroslav's measurements suggested to shift one of the mixer controls from 0..x dB to -x..0 dB and I was just wondering why, since we don't define the ref level in ALSA, hence the shift is kinda arbitrary...
Anyway, I am not pushing for adding an API for reference levels to ALSA. As mentioned for the PA case I decided to shift 0dB to max amplification in any case, which I think is a workable way to avoid this problem.
Lennart
On Wed, Feb 17, 2010 at 01:10:47AM +0100, Lennart Poettering wrote:
On Wed, 17.02.10 12:47, Eliot Blennerhassett (linux@audioscience.com) wrote:
For our cards this is adjustable, but lets say for consumer cards it is fixed. This information is not currently available via the ALSA API.
I wonder how realistic it would even be to add an API for this. i.e. can we even know the refernce level? On many cards most likely not. For example, for my integrated USB speakers speaking of a reference voltage would already be misleading...
Like you say even where we know the actual level it's not practically useful unless it's physically exposed somewhere the user can see it.
For things like line jacks where it is relevant these things do actually get documented relatively often, and obviously measurements are possible where they aren't. I'm not sure how interesting it is unless the system also supports configuration, though.
Lennart Poettering wrote:
On Wed, 17.02.10 12:47, Eliot Blennerhassett (linux@audioscience.com) wrote:
For our cards this is adjustable, but lets say for consumer cards it is fixed. This information is not currently available via the ALSA API.
I wonder how realistic it would even be to add an API for this. i.e. can we even know the refernce level? On many cards most likely not. For example, for my integrated USB speakers speaking of a reference voltage would already be misleading...
Certainly. Same for laptop speakers.
Perhaps could define 0dB as the highest valid volume setting that doesn't cause distortion in the audio when playing a full scale digital signal.
Otherwise the absolute reference might be dBSPL at X metres from the speaker ;) (before anyone answers - in this context I'm joking.)
Yepp, that's the exactly what I was asking, Jaroslav's measurements suggested to shift one of the mixer controls from 0..x dB to -x..0 dB and I was just wondering why, since we don't define the ref level in ALSA, hence the shift is kinda arbitrary...
Anyway, I am not pushing for adding an API for reference levels to ALSA.
We define controls with names like "LineIn0 Level","LineOut1 Level" which we document as having units of dBu.
Given that no other driver has this, its the de-facto standard ;)
As mentioned for the PA case I decided to shift 0dB to max amplification in any case, which I think is a workable way to avoid this problem.
Sure.
On Wed, Feb 17, 2010 at 01:52:11PM +1300, Eliot Blennerhassett wrote:
Lennart Poettering wrote:
I wonder how realistic it would even be to add an API for this. i.e. can we even know the refernce level? On many cards most likely not. For example, for my integrated USB speakers speaking of a reference voltage would already be misleading...
Certainly. Same for laptop speakers.
Perhaps could define 0dB as the highest valid volume setting that doesn't cause distortion in the audio when playing a full scale digital signal.
I think it's something we can leave to be specified for a given bit of hardware - the absolute level doesn't really mean a huge amount unless the user is actually interacting it in some way and going with the reference level that the hardware is using internally means that we get an idea of how much the control is affecting the signal, which is useful for getting an idea of the optimal level to set a given control to (generally the specified 0dB will give the lowest noise, particularly for amplification).
It's when the signal is being presented in a fashion which means it might have to be matched with that on another device that the absolute levels become interesting.
On Wed, 17 Feb 2010, Lennart Poettering wrote:
Yepp, that's the exactly what I was asking, Jaroslav's measurements suggested to shift one of the mixer controls from 0..x dB to -x..0 dB and I was just wondering why, since we don't define the ref level in ALSA, hence the shift is kinda arbitrary...
I think that having a reference level is good for users. For example, some AC97 codecs have Line Out range from -94.5dB .. 0dB , Mixed Line In is in range -34.5dB .. 12dB. So if I set 0dB to Line In and 0dB to Line Out, I would expect to get (if analog parts of soundcard are not assymetric) identical output level as input level.
For USB card as I mentioned, I got Line Out from range -48dB..0dB and Line In in 0dB..48dB. I would assume from the first look to the alsamixer volume bars that the Line In gain is too much.
It's about consistency for users. Rule <0dB attenuation >0dB gain matches this criterium.
The second question is if the represented dB range and scale reported from the driver (hardware and audio chip datasheets) really matches the hardware and how we can measure these values. I suspect a lot of trouble here, because the analog parts of soundcards might have strange curves - it's probably thing you deal with in PA now.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
On Wed, Feb 17, 2010 at 10:04:50AM +0100, Jaroslav Kysela wrote:
I think that having a reference level is good for users. For example, some AC97 codecs have Line Out range from -94.5dB .. 0dB , Mixed Line In is in range -34.5dB .. 12dB. So if I set 0dB to Line In and 0dB to Line Out, I would expect to get (if analog parts of soundcard are not assymetric) identical output level as input level.
That'll tend to be the case for most hardware - the main issues are the fact that we don't currently have a way to tell userspace about the signal path in the device (so knowing which amplifiers are in use at a given time can be tricky) and the fact that you're likely to run into are that you do get fixed gain or attenuation stages in the signal path for various reasons and those currently aren't exposed to user space at all (but that'd probably flop out of doing the routing information).
The second question is if the represented dB range and scale reported from the driver (hardware and audio chip datasheets) really matches the hardware and how we can measure these values. I suspect a lot of trouble here, because the analog parts of soundcards might have strange curves - it's probably thing you deal with in PA now.
Datasheets really should be reliable, and if the curve in the datsheet is too unusual to handle with a range the TLV data format does always allow us to specify subranges (down to individual values for each step) so there's no fundamental problem exposing the information to user space.
I'd actually be surprised if there were too much of an issue with this beyond the data collection one (especially for USB devices).
On Wed, 17.02.10 12:06, Mark Brown (broonie@opensource.wolfsonmicro.com) wrote:
I'd actually be surprised if there were too much of an issue with this beyond the data collection one (especially for USB devices).
I wonder if we could harvest this in some way from the Windows drivers? Does Windows care about the dB data at all? Maybe one could extract this information from their .inf files or so, if they store it there?
At least the Vista APIs seem to expose dB data:
http://msdn.microsoft.com/en-us/library/dd371447%28VS.85%29.aspx
I wonder where they get that data from and what they do with broken hardware like the Aureon... Now I wished I had access to a Windows machine to figure that out...
Lennart
On Wed, Feb 17, 2010 at 02:15:48PM +0100, Lennart Poettering wrote:
I wonder if we could harvest this in some way from the Windows drivers? Does Windows care about the dB data at all? Maybe one could extract this information from their .inf files or so, if they store it there?
It could well be, for this sort of stuff grovelling around in the MSDN driver kit documentation will normally turn something up.
I wonder where they get that data from and what they do with broken hardware like the Aureon... Now I wished I had access to a Windows machine to figure that out...
IME this is dealt with by the manufacturer providing a driver, a device specific driver will bind in preference to a class driver and with Windows it's much more normal to ship a device specific driver along with the device. I've no knowledge of Windows audio drivers, though.
On Wed, 17.02.10 10:04, Jaroslav Kysela (perex@perex.cz) wrote:
The second question is if the represented dB range and scale reported from the driver (hardware and audio chip datasheets) really matches the hardware and how we can measure these values. I suspect a lot of trouble here, because the analog parts of soundcards might have strange curves - it's probably thing you deal with in PA now.
Yes, that is indeed the problem.
For PA I don't care whether the dB curve reported by ALSA might be shifted relative to some reference level, what matters is that otherwise the curve reflects properly how volume increases with higher discrete volume settings.
Lennart
On 17 February 2010 13:06, Lennart Poettering mznyfn@0pointer.de wrote:
On Wed, 17.02.10 10:04, Jaroslav Kysela (perex@perex.cz) wrote:
The second question is if the represented dB range and scale reported from the driver (hardware and audio chip datasheets) really matches the hardware and how we can measure these values. I suspect a lot of trouble here, because the analog parts of soundcards might have strange curves - it's probably thing you deal with in PA now.
Yes, that is indeed the problem.
For PA I don't care whether the dB curve reported by ALSA might be shifted relative to some reference level, what matters is that otherwise the curve reflects properly how volume increases with higher discrete volume settings.
So what you want it this. Example 1: If there are 2 gain controls between the CPU and the line-out. A is at 0dB B is at 0dB
If one changes A to +3dB and B to -3dB and one was playing a quiet sound (so no distortion), the result should sound very similar, volume wise, to the original 0dB, 0dB state.
Example 2: There is one gain control between the CPU and the line-out that we are interested in. A is at 0dB.
If one changes A to +3dB and at the same time modify the source signal digitally by -3dB, the result should sound very similar, volume wise, to the original.
You would have to build your test tool so that it would detect distortion as well as levels.This way you could also find out where the limits really are in the chain.
This is a good aim, but I still think getting the correct 0dB points is more important to ensure the best audio quality. I personally think that PA should just set the hardware ALSA controls to 0dB and do all the volume control in software within PA. The 0dB points in hardware should result in the best sound quality.
James
On Wed, Feb 17, 2010 at 01:55:08PM +0000, James Courtier-Dutton wrote:
I personally think that PA should just set the hardware ALSA controls to 0dB and do all the volume control in software within PA. The 0dB points in hardware should result in the best sound quality.
That's not universally true - for example, with microphones you really do want to have substantial amplification before the ADC sees them, otherwise you'll at best get poor resolution due to the signal being nowhere near full scale. Sometimes this will be done by a fixed gain stage that isn't visible to software, but not always. Things in the digital domain also tend to be at least equivalent to doing the work in the CPU.
On Wed, 17.02.10 13:55, James Courtier-Dutton (james.dutton@gmail.com) wrote:
So what you want it this. Example 1: If there are 2 gain controls between the CPU and the line-out. A is at 0dB B is at 0dB
If one changes A to +3dB and B to -3dB and one was playing a quiet sound (so no distortion), the result should sound very similar, volume wise, to the original 0dB, 0dB state.
Exactly.
Example 2: There is one gain control between the CPU and the line-out that we are interested in. A is at 0dB.
If one changes A to +3dB and at the same time modify the source signal digitally by -3dB, the result should sound very similar, volume wise, to the original.
Exactly. And this second case is what dbverify from my little tool set verifies.
You would have to build your test tool so that it would detect distortion as well as levels.This way you could also find out where the limits really are in the chain.
I am not sure I want to get lost in complexities like that. My simplified world where all elements in the pipeline are perfect, linear multiplicators is oh so cozy, that I am happy to keep my eyes shut and ignore that the actual filters implemented in the various elements might be vastly more complex.
In fact dbmeasure and dbverify pick a 440Hz tone for their tests, so all the volume factors I measure and rely on focus on one point in the frequency spectrum and leave it at that.
Of course, this is a drastic simplification, but it should be good enough on most cards and for desktop audio.
This is a good aim, but I still think getting the correct 0dB points is more important to ensure the best audio quality. I personally think that PA should just set the hardware ALSA controls to 0dB and do all the volume control in software within PA. The 0dB points in hardware should result in the best sound quality.
I don't think this would be a good idea. In a lot of hardware you definitely want to make as much use of the built-in volume adjustment capabilities as you can. For example, on my integrated USB speakers you may control the built-in amplifier with the alsa mixer, and that's definitely much better than attenuating the 16bit PCM stream and having the USB speakers amplifier constantly configured to a very high volume level.
Lennart
On 17 February 2010 14:35, Lennart Poettering mznyfn@0pointer.de wrote:
This is a good aim, but I still think getting the correct 0dB points is more important to ensure the best audio quality. I personally think that PA should just set the hardware ALSA controls to 0dB and do all the volume control in software within PA. The 0dB points in hardware should result in the best sound quality.
I don't think this would be a good idea. In a lot of hardware you definitely want to make as much use of the built-in volume adjustment capabilities as you can. For example, on my integrated USB speakers you may control the built-in amplifier with the alsa mixer, and that's definitely much better than attenuating the 16bit PCM stream and having the USB speakers amplifier constantly configured to a very high volume level.
I was thinking more specifically of the line-out and line-in where knowing the 0dB gain points is very useful and what most people need, with maybe a new dBv or dBu
Mic and Speaker amp levels is a whole other kettle of fish.
2010/2/17 James Courtier-Dutton james.dutton@gmail.com
This is a good aim, but I still think getting the correct 0dB points is more important to ensure the best audio quality. I personally think that PA should just set the hardware ALSA controls to 0dB and do all the volume control in software within PA. The 0dB points in hardware should result in the best sound quality.
James
When you mix two stream of 16-bit audio and send to a 16 bit sound card , you have to add two 16-bit and shift right one bit ,
you have already add -3dB by software when perform soft mixing and you may need to get +3dB gain in DAC if you want to maintain the same dB level if one stream is actually silence
so set the hardware ALSA controls to 0dB is not that good for a sound server
2010/2/17 Eliot Blennerhassett linux@audioscience.com
There are two separate issues here.
- Incorrect dB<->linear mapping
ALSA Volume/Gain controls returning incorrect information about mapping from linear values to dB. E.g. adding "6dB" to the Volume controls while subtracting 6dB in software does not result in 0dB overall gain.
For volume controls the convention is 0dB == multiply by 1.0 == no change. Any sane digital volume control should obey this. For analog volumes, the 0dB position is entirely arbtrary, as I discuss below.
For the alsa db values are in step of 1.5 dB or 3.dB ,
but the software shift one bit is 10 log 2 = 3.0102996* dB
* That 's why adding "6dB" to the Volume controls while subtracting 6dB in software does not result in 0dB overall gain.
2010/2/17 Eliot Blennerhassett linux@audioscience.com
- Absolute calibration of output levels.
(This is *not* required to solve Lennart's problem) This would be required if you wanted two different (brands of) soundcard to output the same voltage for given source pcm.
On windows ,there are benchmark program to compare the sound card 's SNR at different rate , format
can the program be used to measure SNR ?
2010/2/17 Lennart Poettering mznyfn@0pointer.de
Hmm, so you basically tuned the USB card's DAC/ADC level to the HDA card's DAC/ADC.
I now measured the "Master" slider of my aureon (USB 0ccd:0028, TerraTec Aureon 5.1 MkII) with the aforementioned dbmeasure tool and a loopback cable. The aureon has 65536 volume steps, but I was too lazy to measure them all. So I only measured every 3000th. From the max volume to the min volume:
65536 0 dB 62536 0.00560039 dB 59536 0.00694678 dB 56536 0.00616732 dB 53536 0.00645077 dB 50536 0.00673421 dB 47536 -1.49514 dB 44536 -1.49455 dB 41536 -1.49648 dB 38536 -2.98666 dB 35536 -2.98486 dB 32536 -2.98536 dB 29536 -4.48688 dB 26536 -6.00084 dB 23536 -5.99928 dB 20536 -9.00246 dB 17536 -10.5425 dB 14536 -16.5274 dB 11536 -32.9435 dB 8536 -43.4326 dB 5536 -43.5066 dB 2536 -43.2968 dB 0 -43.4431 dB
If you plot this it looks as if the card actually only implements 10 or so discrete steps, and at around 10000 just becomes a constant function.
ALSA reports -47.87 .. -1.97 for this. So it seems the overall range the USB data reports is not really that far off, but the volume function in bteween is.
The noise level of these measurements is < -58 dB.
What's the next step with this measurement data? Will you take it from here, or shall I provide you with more data?
Lennart
How about dbmeasure the pulse device since the volume control seem also have 65536 step ?
Can you provide the result for the pulse device ?
2010/2/17 Jaroslav Kysela perex@perex.cz
On Tue, 16 Feb 2010, Lennart Poettering wrote:
On Tue, 16.02.10 14:40, Mark Brown (broonie@opensource.wolfsonmicro.com)
wrote:
On Tue, Feb 16, 2010 at 03:32:01PM +0100, Lennart Poettering wrote:
On Tue, 16.02.10 09:24, Jaroslav Kysela (perex@perex.cz) wrote:
Line: 0dB..47.81dB # seems correct -47.81dB..0dB Line Capture: -0.18dB..23.81dB # seems correct -17.81dB..6.18dB
Hmm, how did you choose where to put 0dB?
The Line one looks like someone got attenuation and gain confused, which is a fairly common mistake for people to make when copying information from one place to another. Possibly a similar thing going on with the Line Capture control, plus a fixed 6dB gain (which may well be a separate amp...).
I remember that a while back we had a discussion on alsa-devel regarding the fact that ALSA does not define relative to what the dB values reported by the mixer elements actually are measured. Some mixer controls export dB values relative to max amplification (e.g. my integrated USB speakers here), others relative to the output of some other mixer element, and others relative to different standard or not-so-standard output voltages. And there is no API to figure out what the base is.
Now, what Jaroslav listed above suggests that he chose carefully where he put 0dB. I was just wondering about that. Jaroslav, how did you choose where to put 0dB?
Basically, if I remember correctly the discussion, 0dB on all elements should main unchanged volume, <0dB attenuation and >0dB gain. We cannot measure precisely other components on path like analog volume wheels (like SB MP3+ has to change line-out volume), analog amplifiers and other analog signal modificators.
So, if you use one headphones and speakers with defined and fixed volume settings, you can measure differences for the card with broken dB volume ranges. I just used another HDA card in notebook with 0dB settings on all playback controls on path, captured stream from this card on my USB card and played this stream back on my USB card watching and relating the volume levels according dB values. It's not 100% correct, but at least it's something to start with.
Jaroslav
Yes, 0dB for 10 bands graphic equalizer of au8830 should be no gain and no attenuation
how can I calibrate the au8830 10 bands equalizer control as there are 10 bands peak values ?
2010/2/17 Jaroslav Kysela perex@perex.cz
On Tue, 16 Feb 2010, Lennart Poettering wrote:
On Tue, 16.02.10 14:40, Mark Brown (broonie@opensource.wolfsonmicro.com)
wrote:
On Tue, Feb 16, 2010 at 03:32:01PM +0100, Lennart Poettering wrote:
On Tue, 16.02.10 09:24, Jaroslav Kysela (perex@perex.cz) wrote:
Line: 0dB..47.81dB # seems correct -47.81dB..0dB Line Capture: -0.18dB..23.81dB # seems correct -17.81dB..6.18dB
Hmm, how did you choose where to put 0dB?
The Line one looks like someone got attenuation and gain confused, which is a fairly common mistake for people to make when copying information from one place to another. Possibly a similar thing going on with the Line Capture control, plus a fixed 6dB gain (which may well be a separate amp...).
I remember that a while back we had a discussion on alsa-devel regarding the fact that ALSA does not define relative to what the dB values reported by the mixer elements actually are measured. Some mixer controls export dB values relative to max amplification (e.g. my integrated USB speakers here), others relative to the output of some other mixer element, and others relative to different standard or not-so-standard output voltages. And there is no API to figure out what the base is.
Now, what Jaroslav listed above suggests that he chose carefully where he put 0dB. I was just wondering about that. Jaroslav, how did you choose where to put 0dB?
Basically, if I remember correctly the discussion, 0dB on all elements should main unchanged volume, <0dB attenuation and >0dB gain. We cannot measure precisely other components on path like analog volume wheels (like SB MP3+ has to change line-out volume), analog amplifiers and other analog signal modificators.
So, if you use one headphones and speakers with defined and fixed volume settings, you can measure differences for the card with broken dB volume ranges. I just used another HDA card in notebook with 0dB settings on all playback controls on path, captured stream from this card on my USB card and played this stream back on my USB card watching and relating the volume levels according dB values. It's not 100% correct, but at least it's something to start with.
Jaroslav
Refer to http://thread.gmane.org/gmane.linux.alsa.devel/15859
Try to lower "Wave" volume - otherways there will be clipping on bass.
When you set "PCM" to 75 % this is 0 db.
The dB scale of alsa driver was implemented because of 0dB is not at the maximum for emu10k1
On 16 February 2010 15:40, Lennart Poettering mznyfn@0pointer.de wrote:
I remember that a while back we had a discussion on alsa-devel regarding the fact that ALSA does not define relative to what the dB values reported by the mixer elements actually are measured. Some mixer controls export dB values relative to max amplification (e.g. my integrated USB speakers here), others relative to the output of some other mixer element, and others relative to different standard or not-so-standard output voltages. Â And there is no API to figure out what the base is.
Now, what Jaroslav listed above suggests that he chose carefully where he put 0dB. I was just wondering about that. Jaroslav, how did you choose where to put 0dB?
I think what you are trying to do is actually quite difficult. The rules are very simple for digital controls. At 0dB the gain is 0 and the attenuation is 0 so the value going into the control will be identical to the value after the control. The trouble starts at the analogue stages. First we would want to decide on what output we actually want. I think this would depend on the sound card itself. Pro sound cards can output a different set of levels than consumer sound cards. I think the only way to fix the current problem is to determine a sound card that has the correct levels and controls, and then calibrate other sound cards from that. It will take a long time. Up until now, the best we have been able to do is read data sheets and use the values form the data sheets.
I guess a good start would be what digital values should create what voltages on the line output? One can then at least get the 0dB point set right.
Kind Regards
James
On Tue, 16 Feb 2010, James Courtier-Dutton wrote:
I guess a good start would be what digital values should create what voltages on the line output? One can then at least get the 0dB point set right.
It seems that I have to buy a precise voltmeter or good digital oscilloscope to get these results :-) Anyway, the voltage levels expressions are described nicely here:
http://en.wikipedia.org/wiki/Decibel
_From above pro-equipment works with 0.775V as reference volume (0dBu) and consumer electronics with 1V as reference volume (0dBV).
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
2010/2/16 Mark Brown broonie@opensource.wolfsonmicro.com
On Tue, Feb 16, 2010 at 03:32:01PM +0100, Lennart Poettering wrote:
On Tue, 16.02.10 09:24, Jaroslav Kysela (perex@perex.cz) wrote:
Line: 0dB..47.81dB # seems correct -47.81dB..0dB Line Capture: -0.18dB..23.81dB # seems correct -17.81dB..6.18dB
Hmm, how did you choose where to put 0dB?
The Line one looks like someone got attenuation and gain confused, which is a fairly common mistake for people to make when copying information from one place to another. Possibly a similar thing going on with the Line Capture control, plus a fixed 6dB gain (which may well be a separate amp...).
Correct me if I am wrong
0dB point is needed when you recording from line-in by connected loopback cable to line out.
The captured signal is supposed to be the same as the playback signal when you set both playback volume and capture volume to 0dB ,
if you set playback volume over 0dB , clipping occur in the captured signal ,
if the playback volume is less than 0dB , captured signal will be less than the playback signal.
On Tue, 16 Feb 2010, Lennart Poettering wrote:
On Tue, 16.02.10 09:24, Jaroslav Kysela (perex@perex.cz) wrote:
ALSA 1.0.21 (kernel 2.6.32) added a different TLV type that reports the range with the min/max values to minimize those rounding errors.
Unfortunately, it's not the case of a rounding problem. The USB specification is too much vague and vendors don't use the dB range correctly. For example, I tested SB MP3+ USB device and reported ranges were:
Master: -47.87dB..0.06dB # correct Line: 0dB..47.81dB # seems correct -47.81dB..0dB Line Capture: -0.18dB..23.81dB # seems correct -17.81dB..6.18dB
Hmm, how did you choose where to put 0dB?
It's just tested against another hw using one headphones.
http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=c3a3e040f01457...
The SB MP3+ uses AC97 codec AD1995 with some own ASIC from Creative. So I think that even the 47.87 values are not correct and the real ranges are from -48dB..0dB and -18dB..6dB.
So if I understand this correctly, then the way to handle issues like this is to measure the dB data for each USB card in question and then update the drivers with quirks accordingly?
Basically, yes, these values should be corrected early as possible.
So if I want my Aureon to work properly I better start measuring now?
Would it be feasible to allow overriding of the dB data from userspace, i.e. from the alsa mixer init db perhaps?
It's another possibility. But the right place to handle this issue is alsa-lib and parsing a text file with the new data.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
On Tue, 16.02.10 09:08, Clemens Ladisch (clemens@ladisch.de) wrote:
Lennart Poettering wrote:
Getting back to the invalid dB data from the USB cards: the question is whether the USB descriptor data is badly parsed, and the dB mismatch hence systematic for USB cards,
USB descriptors use units of 1/256th dB, while ALSA uses 1/100th dB. When the level is computed from the minimum plus a multiple of the step size, rounding errors add up considerately.
ALSA 1.0.21 (kernel 2.6.32) added a different TLV type that reports the range with the min/max values to minimize those rounding errors.
I am really sure that the discrepancy I measure with the Aureon is way beyond rounding errors.
Lennart
2010/2/16 Lennart Poettering mznyfn@0pointer.de
On Tue, 16.02.10 09:08, Clemens Ladisch (clemens@ladisch.de) wrote:
Lennart Poettering wrote:
Getting back to the invalid dB data from the USB cards: the question is whether the USB descriptor data is badly parsed, and the dB mismatch hence systematic for USB cards,
USB descriptors use units of 1/256th dB, while ALSA uses 1/100th dB. When the level is computed from the minimum plus a multiple of the step size, rounding errors add up considerately.
ALSA 1.0.21 (kernel 2.6.32) added a different TLV type that reports the range with the min/max values to minimize those rounding errors.
I am really sure that the discrepancy I measure with the Aureon is way beyond rounding errors.
Lennart
if the program use a format FLOAT_LE which is not supported by the hardware and need to use plughw , you have already added error ( resampling and format conversion ) to the result
On Wed, 17.02.10 11:30, Raymond Yau (superquad.vortex2@gmail.com) wrote:
2010/2/16 Lennart Poettering mznyfn@0pointer.de
On Tue, 16.02.10 09:08, Clemens Ladisch (clemens@ladisch.de) wrote:
Lennart Poettering wrote:
Getting back to the invalid dB data from the USB cards: the question is whether the USB descriptor data is badly parsed, and the dB mismatch hence systematic for USB cards,
USB descriptors use units of 1/256th dB, while ALSA uses 1/100th dB. When the level is computed from the minimum plus a multiple of the step size, rounding errors add up considerately.
ALSA 1.0.21 (kernel 2.6.32) added a different TLV type that reports the range with the min/max values to minimize those rounding errors.
I am really sure that the discrepancy I measure with the Aureon is way beyond rounding errors.
Lennart
if the program use a format FLOAT_LE which is not supported by the hardware and need to use plughw , you have already added error ( resampling and format conversion ) to the result
That numeric noise is neglible in contrast to the big (20dB or so?) discrepancy I am seeing here.
Lennart
2010/2/17 Lennart Poettering mznyfn@0pointer.de
On Wed, 17.02.10 11:30, Raymond Yau (superquad.vortex2@gmail.com) wrote:
2010/2/16 Lennart Poettering mznyfn@0pointer.de
On Tue, 16.02.10 09:08, Clemens Ladisch (clemens@ladisch.de) wrote:
if the program use a format FLOAT_LE which is not supported by the
hardware
and need to use plughw , you have already added error ( resampling and format conversion ) to the result
That numeric noise is neglible in contrast to the big (20dB or so?) discrepancy I am seeing here.
Lennart
For HDA , some codec can playback/record in 16 , 20, 24 or 32 bits , if you are using non-native format ,
I think there should be some practical difference when HDA codec use 16 , 24, or 32 bits for running your test
On Mon, 15 Feb 2010, Lennart Poettering wrote:
Heya,
a while back I wrote a little tool "dbmeasure" which can be used to determine dB attenuation data for alsa mixer controls. I have now extended this little dB tools suite to include a tiny tool "dbverify" that can be used to verify the correctness of existing dB data exposed by the drivers. It should be relatively easy to use that tool, suitable even for non-guru folks who want to debug the dB information from alsa.
http://git.0pointer.de/?p=dbmeasure.git git://git.0pointer.de/dbmeasure.git
Thank you for this code. I'm playing with an idea to start gathering of all ALSA tests around and make a GUI for them. But it might make sense to use something more portable than C language and use standard ALSA tools (amixer, aplay) as backends ;-)
For USB cards, the dB ranges read from hw are not correct. We have to overwrite these bad values in the driver. Unfortunately, the USB driver doesn't show the USB descriptor -> ALSA control mapping to gather all necessary information for the code updates. I'm working on a patch right now to obtain this information using procfs.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
On Tue, 16 Feb 2010, Jaroslav Kysela wrote:
On Mon, 15 Feb 2010, Lennart Poettering wrote:
Heya,
a while back I wrote a little tool "dbmeasure" which can be used to determine dB attenuation data for alsa mixer controls. I have now extended this little dB tools suite to include a tiny tool "dbverify" that can be used to verify the correctness of existing dB data exposed by the drivers. It should be relatively easy to use that tool, suitable even for non-guru folks who want to debug the dB information from alsa.
http://git.0pointer.de/?p=dbmeasure.git git://git.0pointer.de/dbmeasure.git
Thank you for this code. I'm playing with an idea to start gathering of all ALSA tests around and make a GUI for them. But it might make sense to use something more portable than C language and use standard ALSA tools (amixer, aplay) as backends ;-)
For USB cards, the dB ranges read from hw are not correct. We have to overwrite these bad values in the driver. Unfortunately, the USB driver doesn't show the USB descriptor -> ALSA control mapping to gather all necessary information for the code updates. I'm working on a patch right now to obtain this information using procfs.
The patch is available here:
http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=6daf48108cb013...
I also updated the alsa-info.sh script to gather this information.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
2010/2/16 Lennart Poettering mznyfn@0pointer.de
Heya,
a while back I wrote a little tool "dbmeasure" which can be used to determine dB attenuation data for alsa mixer controls. I have now extended this little dB tools suite to include a tiny tool "dbverify" that can be used to verify the correctness of existing dB data exposed by the drivers. It should be relatively easy to use that tool, suitable even for non-guru folks who want to debug the dB information from alsa.
http://git.0pointer.de/?p=dbmeasure.git git://git.0pointer.de/dbmeasure.git
Just run "make" in a git checkout and then try:
$ ./dbverify Aureon51MkII Master 30 200
That will verify the dB data of the "Master" control of the sound card that goes by the id "Aureon51MkII". It will compare the discrete volume steps 30 and 200: first it will play a full amplitude sine wave at mixer volume step 30, and then will change to mixer volume step 200, but attenuate the sine wave in software compensating for the volume change. So once you hear the sine wave attenuated by the hw, and once by the software. If the card's dB data is correct both sines should have the same volume.
Now, playing around with this, I could verify what I already mentioned to Jarsolav elsewhere earlier: it seems that particularly USB cards seem to expose invalid dB data (at least all mine do). For example, for the above mentioned Aureon 5.1 it's really *way* off -- if you posess that card just run the line above, and listen to the difference. It's really bad. OTOH the dB data of the HDA cards I own is pretty accurate as it seems, at least I was unable to decide just by listening which sine wave was attenuated by sw, and which by hw.
Getting back to the invalid dB data from the USB cards: the question is whether the USB descriptor data is badly parsed, and the dB mismatch hence systematic for USB cards, or if these cards are just crappy and include invalid data? In which case I wonder what we could do about that? The Aureon's dB range already looks suspicous, since both the max and the min dB value are < 0 (-47.69 to -1.97), so maybe we could add some heuristics to filter out data that already looks suspicous?
Invalid dB data from the driver is a real problem for the "flat volume" logic in PA. We basically allow each app to control the full hw volume range individually, and then set the hw volume to the max of what all apps wanted and attenuate the other streams accordingly. On the Aureon this doesn't work at all, since the attenuation of the streams is miscalculated due to the invalid dB data.
Lennart
Refer to README
WHAT YOU NEED?
a) A sound card where input and output are synchronous b) A feedback cable that allows you to feed sound card output
how do I know my sound card support synchronous playback and capture ?
do you program able to find out whether the sound card support synchronous playback and capture ?
do your result still valid if the sound card does not support synchronous playback and capture ?
do the result different if I use analog loop back of the ac97 codec instead of a loop back cable ?
On Wed, 17.02.10 11:44, Raymond Yau (superquad.vortex2@gmail.com) wrote:
WHAT YOU NEED?
a) A sound card where input and output are synchronous b) A feedback cable that allows you to feed sound card outputhow do I know my sound card support synchronous playback and capture ?
We had a discussion about that on alsa-devel a month back or so. The conclusion was basically that software may assume that playback and capturing on the same card is clocked the same way and that is all this tool needs.
do you program able to find out whether the sound card support synchronous playback and capture ?
No.
do your result still valid if the sound card does not support synchronous playback and capture ?
It's fine if there is a constant phase shift between what you play back and record. What matters is that the clock of playback and clock of capture have the same speed. The tool will sum up a recorded sample window a couple of times to reduce the noise level below some threshold, and for that to work we need to make sure that our sine wave isn't shifted each time we sum it up.
do the result different if I use analog loop back of the ac97 codec instead of a loop back cable ?
Presumably.
Lennart
2010/2/16 Lennart Poettering mznyfn@0pointer.de
Invalid dB data from the driver is a real problem for the "flat volume" logic in PA. We basically allow each app to control the full hw volume range individually, and then set the hw volume to the max of what all apps wanted and attenuate the other streams accordingly. On the Aureon this doesn't work at all, since the attenuation of the streams is miscalculated due to the invalid dB data.
Lennart
Refer to http://pulseaudio.org/wiki/BadDecibel
If (when flat volumes are enabled in PulseAudio) the playback volume of one stream changes whenever another stream is played, this is most likely caused be incorrect dB attenuation data exposed by the ALSA kernel driver.
This seem to the software attenuation of the playback volume when PA software mix two or more playback streams
2010/2/16 Lennart Poettering mznyfn@0pointer.de
Heya,
Invalid dB data from the driver is a real problem for the "flat volume" logic in PA. We basically allow each app to control the full hw volume range individually, and then set the hw volume to the max of what all apps wanted and attenuate the other streams accordingly. On the Aureon this doesn't work at all, since the attenuation of the streams is miscalculated due to the invalid dB data.
Lennart
The real problem for the "flat volume" logic in PA is when you set the hardware device volume to maximum, you cannot compensate the software attent when PA software mixing two or more audio stream by increase the gain in DAC
2010/2/16 Lennart Poettering mznyfn@0pointer.de
Heya,
Invalid dB data from the driver is a real problem for the "flat volume" logic in PA. We basically allow each app to control the full hw volume range individually, and then set the hw volume to the max of what all apps wanted and attenuate the other streams accordingly. On the Aureon this doesn't work at all, since the attenuation of the streams is miscalculated due to the invalid dB data.
Lennart
But PA also did not provide dB information to alsa application through alsa-pulse plugin
amixer -D pulse Simple mixer control 'Master',0 Capabilities: pvolume pswitch pswitch-joined Playback channels: Front Left - Front Right Limits: Playback 0 - 65536 Mono: Front Left: Playback 65536 [100%] [on] Front Right: Playback 65536 [100%] [on] Simple mixer control 'Capture',0 Capabilities: cvolume cswitch cswitch-joined Capture channels: Front Left - Front Right Limits: Capture 0 - 65536 Front Left: Capture 65536 [100%] [on] Front Right: Capture 65536 [100%] [on]
2010/2/16 Lennart Poettering mznyfn@0pointer.de
Heya,
a while back I wrote a little tool "dbmeasure" which can be used to determine dB attenuation data for alsa mixer controls. I have now extended this little dB tools suite to include a tiny tool "dbverify" that can be used to verify the correctness of existing dB data exposed by the drivers. It should be relatively easy to use that tool, suitable even for non-guru folks who want to debug the dB information from alsa.
http://git.0pointer.de/?p=dbmeasure.git git://git.0pointer.de/dbmeasure.git
Just run "make" in a git checkout and then try:
$ ./dbverify Aureon51MkII Master 30 200
That will verify the dB data of the "Master" control of the sound card that goes by the id "Aureon51MkII". It will compare the discrete volume steps 30 and 200: first it will play a full amplitude sine wave at mixer volume step 30, and then will change to mixer volume step 200, but attenuate the sine wave in software compensating for the volume change. So once you hear the sine wave attenuated by the hw, and once by the software. If the card's dB data is correct both sines should have the same volume.
Lennart
Finally have time and an analog loop back cable to test your program dbverify.c
It really depend on your ear to do the verifcation which is not really scientific
Unfortunately , I am unable to run dbmeasure on both of my au8830 and HDA sound card
Can you provide any test result of your HDA sound card ?
!) The program dbmeasure.c seem underrun easily since you start the device and waiting for the user to press enter key
2) it expect the sound driver can provide exactly 1 second buffer because your logic is generate one second sample, Neither au8830 nor HDA driver can provide exactly one second buffer
participants (8)
-
Clemens Ladisch -
Eliot Blennerhassett -
James Courtier-Dutton -
Jaroslav Kysela -
Lennart Poettering -
Mads Kiilerich -
Mark Brown -
Raymond Yau