[pulseaudio-discuss] Reverting ade0a6f88464d8aecf83982d400ccfc402341920
Hello, Should this commit be reverted? http://git.0pointer.de/?p=pulseaudio.git;a=commit;h=ade0a6f88464d8aecf83982d400ccfc402341920 I don't know what problem that commit solves, but it introduces a new problem: if Pulseaudio requests a volume that is above 0dB in the alsa volume element scale, then it can easily happen that alsa will round the request down. That rounding is then compensated with software volume, which in this case is amplification. We don't want software amplification, or do we? -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Reverting ade0a6f88464d8aecf83982d400ccfc402341920
'Twas brillig, and Tanu Kaskinen at 13/05/11 08:49 did gyre and gimble:
Hello,
Should this commit be reverted?
http://git.0pointer.de/?p=pulseaudio.git;a=commit;h=ade0a6f88464d8aecf83982d400ccfc402341920
I don't know what problem that commit solves, but it introduces a new
problem: if Pulseaudio requests a volume that is above 0dB in the alsa
volume element scale, then it can easily happen that alsa will round the
request down. That rounding is then compensated with software volume,
which in this case is amplification. We don't want software
amplification, or do we?
Wow spooky. Strangely enough I've already got this one reverted in my tree!
I found that when adding source output volumes (which I will publish
after Arun's passthrough work is merged), that this caused really
strange issues with volume.
This is the commit in my tree that solved that:
commit 8b595ac248d7ca48e28c3e4e84f1eaf4abf5439d
Author: Colin Guthrie co...@mageia.org
Date: Sun May 8 12:44:50 2011 +0100
alsa-mixer: Reverse rounding direction for sources.
The previous logic in ade0a6f88464d8aecf83982d400ccfc402341920
does not work with for input volumes.
In the case of input 0dB is typically the point at which ALSA sliders
are their minimum. This means that when the ALSA mixer is at it's
maximum it could be applying e.g. +22.5dB.
Considering a step size of ±1.5dB, if we request +22dB, the current
system will ultimate set the h/w to +21dB (one step below +22.5dB)
because it rounds towards 0. This means that software has to amplify the
signal back up to +22dB which is obviously not ideal for the data
integrity. So for inputs we should always go higher than we request if
possible and then attenuate in software back down to the level
requested.
diff --git a/src/modules/alsa/alsa-mixer.c b/src/modules/alsa/alsa-mixer.c
index f236da0..1d9a91a 100644
--- a/src/modules/alsa/alsa-mixer.c
+++ b/src/modules/alsa/alsa-mixer.c
@@ -893,7 +893,7 @@ static int element_set_volume(pa_alsa_element *e,
snd_mixer_t *m, const pa_chann
if (e-has_dB) {
long value = to_alsa_dB(f);
-int rounding = value 0 ? -1 : +1;
+int rounding;
if (e-volume_limit = 0 value (e-max_dB * 100))
value = e-max_dB * 100;
@@ -903,6 +903,7 @@ static int element_set_volume(pa_alsa_element *e,
snd_mixer_t *m, const pa_chann
* if the channel is available, ALSA behaves very
* strangely and doesn't fail the call */
if (snd_mixer_selem_has_playback_channel(me, c)) {
+rounding = value 0 ? -1 : +1;
if (e-db_fix) {
if (write_to_hw)
r = snd_mixer_selem_set_playback_volume(me,
c, decibel_fix_get_step(e-db_fix, value, rounding));
@@ -925,6 +926,7 @@ static int element_set_volume(pa_alsa_element *e,
snd_mixer_t *m, const pa_chann
r = -1;
} else {
if (snd_mixer_selem_has_capture_channel(me, c)) {
+rounding = value 0 ? +1 : -1;
if (e-db_fix) {
if (write_to_hw)
r = snd_mixer_selem_set_capture_volume(me,
c, decibel_fix_get_step(e-db_fix, value, rounding));
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mageia Contributor [http://www.mageia.org/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Reverting ade0a6f88464d8aecf83982d400ccfc402341920
'Twas brillig, and Colin Guthrie at 13/05/11 09:06 did gyre and gimble: Wow spooky. Strangely enough I've already got this one reverted in my tree! I didn't mean to use the word reverted there but you catch my drift I'm sure. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Is there any way to remap source channels?
Hi, is there any way to remap source channels? I need the same functionality as provided by module-remap-sink, but for sources - I use multichannel soundcard (RME Hammerfall) and I want to create virtual sources that map to stereo pairs of my inputs. Then I want to use their names in my application. Thank you, m. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Is there any way to remap source channels?
On Fri, 2011-05-13 at 11:30 +0200, mar...@saepia.net wrote: Hi, is there any way to remap source channels? I need the same functionality as provided by module-remap-sink, but for sources - I use multichannel soundcard (RME Hammerfall) and I want to create virtual sources that map to stereo pairs of my inputs. Then I want to use their names in my application. module-remap-source would be nice to have. But we don't have it. A very ugly hack, which I'm not sure even works, would be to configure the channel map of the sound card to have only aux channels (required to prevent remixing), then load a null sink with two channels (channel map matched to the desired channels on the sound card), then load module-loopback that loops the sound card to the null sink. Then you can record from the null sink's monitor. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Is there any way to remap source channels?
Why should I prevent remixing? Can't I just use module-loopback with channel_map set? m. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Reverting ade0a6f88464d8aecf83982d400ccfc402341920
'Twas brillig, and David Henningsson at 13/05/11 16:29 did gyre and gimble: On 2011-05-13 09:49, Tanu Kaskinen wrote: Hello, Should this commit be reverted? No. http://git.0pointer.de/?p=pulseaudio.git;a=commit;h=ade0a6f88464d8aecf83982d400ccfc402341920 I don't know what problem that commit solves,but it introduces a new problem: if Pulseaudio requests a volume that is above 0dB in the alsa volume element scale, then it can easily happen that alsa will round the request down. That rounding is then compensated with software volume, which in this case is amplification. We don't want software amplification, or do we? In short; if we e g have Mic Boost levels at (0dB, 20dB, 40dB and 60dB) and the user wants 30 dB, better have 20dB in hardware and +10dB in software than 40dB in hardware and -10dB in software, as the latter one is more likely to have digital distortion when the signal passes through the ADC. I can see the point in this, but there is still something ultimately wrong in the logic when dealing with pa_cvolume_divide when calculating what volume to write to the h/w (this is in an uncommitted patch to add flat volumes to sources and thus volume controls to source outputs). By rounding in this direction I find the calculated h/w volume very sporadic whereby ramping up the volume smoothly in PA will actually cause the alsa volume to go up and down as it climbs e.g. at 72% alsa was at e.g. +16dB and at 73% it was at +14.5dB which makes no logical sense. Perhaps the logic behind using pa_cvolume_divide has not been ported properly (by me) in my patch, but I think we'll need to look at this approach a bit to try and work out what's happening and how to fix it. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Is there any way to remap source channels?
On Fri, 2011-05-13 at 14:14 +0200, mar...@saepia.net wrote: Why should I prevent remixing? Can't I just use module-loopback with channel_map set? I think this is what happens (I haven't tested): if you have non-aux channels on the sound card, let's say front-left, front-right, rear-left and rear-right, and you try to loop back just rear-left and rear-right, the resampler (which really takes care of more conversion than just sample rate) will try to be smart and mix some of front-left and front-right into the rear-left and rear-right channels. The same logic is involved always when a stream - be it capture or playback - is connected to a device that doesn't have the same parameters as the stream. Configuring the device to use aux channels should disable the intelligent remixing - only the channels specified by the stream will be taken from the source. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Is there any way to remap source channels?
'Twas brillig, and Tanu Kaskinen at 13/05/11 16:55 did gyre and gimble: On Fri, 2011-05-13 at 14:14 +0200, mar...@saepia.net wrote: Why should I prevent remixing? Can't I just use module-loopback with channel_map set? I think this is what happens (I haven't tested): if you have non-aux channels on the sound card, let's say front-left, front-right, rear-left and rear-right, and you try to loop back just rear-left and rear-right, the resampler (which really takes care of more conversion than just sample rate) will try to be smart and mix some of front-left and front-right into the rear-left and rear-right channels. The same logic is involved always when a stream - be it capture or playback - is connected to a device that doesn't have the same parameters as the stream. Configuring the device to use aux channels should disable the intelligent remixing - only the channels specified by the stream will be taken from the source. FWIW, some modules, like module-remap-sink take a remix=yes|no argument to control this behaviour even when using standard channel names. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Reverting ade0a6f88464d8aecf83982d400ccfc402341920
On Fri, 2011-05-13 at 17:29 +0200, David Henningsson wrote: In short; if we e g have Mic Boost levels at (0dB, 20dB, 40dB and 60dB) and the user wants 30 dB, better have 20dB in hardware and +10dB in software than 40dB in hardware and -10dB in software, as the latter one is more likely to have digital distortion when the signal passes through the ADC. There is a longer email on this list a while back, explaining more of the philosophy behind, but I can't seem to find it right now. Ok, I think I understand why rounding down makes sense when recording. With playback, however, rounding towards 0 dB is definetely broken. My ability to think clearly happens to be currently a bit weakened, so I have to ask you: what's so magic about 0 dB? With playback rounding should always be done up - would it make sense to round always down with capture? -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Is there any way to remap source channels?
On Fri, 2011-05-13 at 17:05 +0100, Colin Guthrie wrote: FWIW, some modules, like module-remap-sink take a remix=yes|no argument to control this behaviour even when using standard channel names. module-loopback should have a similar argument, but it doesn't... -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Is there any way to remap source channels?
Ok, I understand. Fortunately, I need to route aux channels - SPDIF input in my soundcard has ID 17 and 18... During study of GStreamer's pulsesrc element I found that one has got implemented some logic for channel mapping, but there are no examples how to use it. Maybe it would be enough to choose the right channels. Thank you! m. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Reverting ade0a6f88464d8aecf83982d400ccfc402341920
On 2011-05-13 18:20, Tanu Kaskinen wrote: On Fri, 2011-05-13 at 17:29 +0200, David Henningsson wrote: In short; if we e g have Mic Boost levels at (0dB, 20dB, 40dB and 60dB) and the user wants 30 dB, better have 20dB in hardware and +10dB in software than 40dB in hardware and -10dB in software, as the latter one is more likely to have digital distortion when the signal passes through the ADC. There is a longer email on this list a while back, explaining more of the philosophy behind, but I can't seem to find it right now. Ok, I think I understand why rounding down makes sense when recording. With playback, however, rounding towards 0 dB is definetely broken. My ability to think clearly happens to be currently a bit weakened, so I have to ask you: what's so magic about 0 dB? Here's how I wrote it a while ago, quoting a thread named Mic Input Volume Controls: We want to maximise quality while avoiding digital distortion, that's basically the problem in a nutshell. We're assuming (sometimes incorrectly; but that's our best guess) that this golden spot will be achieved with all sliders at 0 dB. I think my approach makes sense, unless I'm missing something: If we're aiming for something above 0 dB, let's round down to make sure we avoid distortion, and if we're below 0 dB, let's round up to make sure we get maximum quality. And then we always start with the control that's closest to the physical hardware and work our way in. Rethinking that, I don't think I've ever seen any playback volume control that goes above 0 dB. All HDA's I've seen go up to 0 dB only, whereas for recording there is both above and below 0 dB. Therefore the scenario you state has not crossed my mind. So maybe you're right about always rounding up with playback. If there actually was a say +6 dB switch and you wanted +4 dB, then we should do +6 dB in hw and -2 dB in sw as +4 dB in software would potentially cause digital distortion. Right? With playback rounding should always be done up - would it make sense to round always down with capture? Maybe, if we give up the thought of 0 dB being magic. -- David Henningsson http://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
