summaryrefslogtreecommitdiff
path: root/Software/PulseAudio/Backends
diff options
context:
space:
mode:
authorJoe Rayhawk <jrayhawk@freedesktop.org>2013-05-18 01:32:37 -0700
committerJoe Rayhawk <jrayhawk@freedesktop.org>2013-05-18 01:32:37 -0700
commit4f950c0adcd7555eb5c1fd0e5f835130f3d75dfd (patch)
tree98abb3112dd43eda66e13aaec89d7eb2754e9b91 /Software/PulseAudio/Backends
parent7fd5ba2d8bdff4802b084c2901a122cdd6ececa3 (diff)
moin2mdwn: convert page Software/PulseAudio/Backends/ALSA/Decibel
Diffstat (limited to 'Software/PulseAudio/Backends')
-rw-r--r--Software/PulseAudio/Backends/ALSA/Decibel.mdwn (renamed from Software/PulseAudio/Backends/ALSA/Decibel.moin)87
1 files changed, 44 insertions, 43 deletions
diff --git a/Software/PulseAudio/Backends/ALSA/Decibel.moin b/Software/PulseAudio/Backends/ALSA/Decibel.mdwn
index 475ecabc..011e1259 100644
--- a/Software/PulseAudio/Backends/ALSA/Decibel.moin
+++ b/Software/PulseAudio/Backends/ALSA/Decibel.mdwn
@@ -1,43 +1,44 @@
-<<Include(Software/PulseAudio/TOC)>>
-[[../|↩ Back to ALSA]]
-
-= Debugging Bad dB Information of ALSA Drivers =
-
-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.
-
-To debug and verify that via a listening test, use the "dbverify" tool from by "dbmeasure" tool set:
-
-{{{
-http://git.0pointer.de/?p=dbmeasure.git
-git://git.0pointer.de/dbmeasure.git
-}}}
-
-The tool requires only minimal dependencies: besides the libc headers only the alsa headers. It is independent of !PulseAudio. After a git checkout and a "make", you may run dbverify like this:
-
-{{{
-$ ./dbverify Aureon51MkII Master 30 200
-}}}
-
-This will test the dB data of the "Master" mixer control of the "Aureon51MkII" sound card for the mixer volume steps 30 and 200 (note that this assumes you have at least 200 volume steps. How many you have depends on hardware and driver. See below). The list of sound card ids for the first parameter you may find by issuing:
-
-{{{
-$ cat /proc/asound/cards
-}}}
-
-The ALSA card ID string is enclosed in []. Instead of card names you may also use ALSA card indexes as first parameter to dbverify. The list of suitable mixer controls for the second parameter of dbverify you may list with:
-
-{{{
-amixer -D hw:Aureon51MkII | grep "Simple mixer control"
-}}}
-
-If the third and fourth parameter to dbverify are ommited, the tool will test the loudest volume setting against the softest one. If those arguments are specified the tool will compare these two discrete volumes. It is advisable to play around with these values to compare multiple volume steps of the hardware. It is especially wise to pick your own values if the lowest hw volume setting is too silent to be audible. That said it might make sense to omit these arguments when starting your testing. This will then also show you the available volume step range of your card and you can then pick other values to tes from that range.
-
-The tool will play a 1s sine wave twice and in a loop, and attenuate it once in software and once in hardware. The effect should be that the wave should have the same volume both times if the dB information is reliable. If the dB data is not correct, then they will have different volumes.
-
-The command line mentioned above will test the "Master" mixer element of your card. Of course, usually this is not the only mixer element in the audio pipeline, which means after you tested "Master" you might want to test "PCM" and "Speaker", too, and possibly others ("Front", ... the available controls depend on the card and driver).
-
-If this listening test reveals that the dB information of your driver is not correct, then please file a bug on your respective distribution bug tracker or the kernel bugzilla (and NOT the !PulseAudio bug tracker!). If you want to help even more then consider measuring the correct dB data for your card. Use the dbmeasure tool from the same git repo for that. You'll need a loopback cable for that to connect line out with line in, a lot of time and a little bit of technical expertise. For more details see the [[http://git.0pointer.de/?p=dbmeasure.git;a=blob_plain;f=README|README]] of dbmeasure. Make sure to file a bug in your distributions bug tracker/kernel bugzilla and ask for your data to be included as a quirk update for your driver (that means also include the output of alsa-info.sh --no-upload in that bug report).
-
-There's a temporary workaround to make PA skip the invalid dB data. But ha! I won't write down how that works here, to make sure that you really file that bug. Muahaha. Mauahahahahah!
-
-Also see the [[http://mailman.alsa-project.org/pipermail/alsa-devel/2010-February/025213.html|original announcement mail for dbverify]]!
+
+[[!inline pages="Software/PulseAudio/TOC" quick="yes" raw="yes"]] [[↩ Back to ALSA|Software/PulseAudio/Backends/ALSA]]
+
+
+# Debugging Bad dB Information of ALSA Drivers
+
+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.
+
+To debug and verify that via a listening test, use the "dbverify" tool from by "dbmeasure" tool set:
+
+
+[[!format txt """
+http://git.0pointer.de/?p=dbmeasure.git
+git://git.0pointer.de/dbmeasure.git
+"""]]
+The tool requires only minimal dependencies: besides the libc headers only the alsa headers. It is independent of PulseAudio. After a git checkout and a "make", you may run dbverify like this:
+
+
+[[!format txt """
+$ ./dbverify Aureon51MkII Master 30 200
+"""]]
+This will test the dB data of the "Master" mixer control of the "Aureon51MkII" sound card for the mixer volume steps 30 and 200 (note that this assumes you have at least 200 volume steps. How many you have depends on hardware and driver. See below). The list of sound card ids for the first parameter you may find by issuing:
+
+
+[[!format txt """
+$ cat /proc/asound/cards
+"""]]
+The ALSA card ID string is enclosed in []. Instead of card names you may also use ALSA card indexes as first parameter to dbverify. The list of suitable mixer controls for the second parameter of dbverify you may list with:
+
+
+[[!format txt """
+amixer -D hw:Aureon51MkII | grep "Simple mixer control"
+"""]]
+If the third and fourth parameter to dbverify are ommited, the tool will test the loudest volume setting against the softest one. If those arguments are specified the tool will compare these two discrete volumes. It is advisable to play around with these values to compare multiple volume steps of the hardware. It is especially wise to pick your own values if the lowest hw volume setting is too silent to be audible. That said it might make sense to omit these arguments when starting your testing. This will then also show you the available volume step range of your card and you can then pick other values to tes from that range.
+
+The tool will play a 1s sine wave twice and in a loop, and attenuate it once in software and once in hardware. The effect should be that the wave should have the same volume both times if the dB information is reliable. If the dB data is not correct, then they will have different volumes.
+
+The command line mentioned above will test the "Master" mixer element of your card. Of course, usually this is not the only mixer element in the audio pipeline, which means after you tested "Master" you might want to test "PCM" and "Speaker", too, and possibly others ("Front", ... the available controls depend on the card and driver).
+
+If this listening test reveals that the dB information of your driver is not correct, then please file a bug on your respective distribution bug tracker or the kernel bugzilla (and NOT the PulseAudio bug tracker!). If you want to help even more then consider measuring the correct dB data for your card. Use the dbmeasure tool from the same git repo for that. You'll need a loopback cable for that to connect line out with line in, a lot of time and a little bit of technical expertise. For more details see the [[README|http://git.0pointer.de/?p=dbmeasure.git;a=blob_plain;f=README]] of dbmeasure. Make sure to file a bug in your distributions bug tracker/kernel bugzilla and ask for your data to be included as a quirk update for your driver (that means also include the output of alsa-info.sh --no-upload in that bug report).
+
+There's a temporary workaround to make PA skip the invalid dB data. But ha! I won't write down how that works here, to make sure that you really file that bug. Muahaha. Mauahahahahah!
+
+Also see the [[original announcement mail for dbverify|http://mailman.alsa-project.org/pipermail/alsa-devel/2010-February/025213.html]]!