Re: [pulseaudio-discuss] On scaling the HRIR in module-virtual-surround-sink
On Thu, 2014-04-03 at 21:36 -0500, CCOR58 wrote: Have I subscribed to the wrong list? I originally thought this was a help type list, but it appears to be more of a developer's forum. This list is for both kinds of discussions. I was looking for a forum where I could get a better understanding of the overall linux audio system; ie ALSA, Jack Audio, pulse audio and hardware and how they all interact. The individual .net or .org sites for each of these separate entities are detailed about their own projects but seem somewhat vague about how they all tie together. I thought I understood them and had a box running Mint 16 ALSA JACK PULSE and when I set up the jack patch system and understood what was a dedicated connection; feeding a 1004 Hz tone into the line in on the hardware seemed to be fed everywhere and same with a mic which caused feedback loop and loud squeal. From what I read once everything showed up in the jack connections panel, jack had control and this strange feedback should not have occurred. What connections did you have in jack? If you had no connections at all, then this sounds like the alsa mixer settings were set up so that there was a direct loop in the hardware from line in to speakers. AFAIK, Jack doesn't control the alsa mixer settings at all, and certainly not those settings that can cause loops. You can hopefully fix this with alsamixer. alsamixer has three modes that can be cycled with the tab key: Playback, Capture and All. If you select the Playback mode (which is the default anyway) and you see volume/mute elements that refer to input (e.g. Mic), make sure those are muted, because if Mic playback is not muted, it means that the mic input is played to the speakers (or whatever output is enabled). -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] On scaling the HRIR in module-virtual-surround-sink
Have I subscribed to the wrong list? I originally thought this was a help type list, but it appears to be more of a developer's forum. I was looking for a forum where I could get a better understanding of the overall linux audio system; ie ALSA, Jack Audio, pulse audio and hardware and how they all interact. The individual .net or .org sites for each of these separate entities are detailed about their own projects but seem somewhat vague about how they all tie together. I thought I understood them and had a box running Mint 16 ALSA JACK PULSE and when I set up the jack patch system and understood what was a dedicated connection; feeding a 1004 Hz tone into the line in on the hardware seemed to be fed everywhere and same with a mic which caused feedback loop and loud squeal. From what I read once everything showed up in the jack connections panel, jack had control and this strange feedback should not have occurred. So if I am posting to wrong list I apologize and would appreciate a link to a more appropriate list Thanks ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] On scaling the HRIR in module-virtual-surround-sink
Hello Alexander, On Tuesday 11 March 2014, 15:00:31, Tanu Kaskinen wrote: On Sun, 2014-03-09 at 00:57 +0600, Alexander E. Patrakov wrote: Hello. [Do not blindly apply patches from this e-mail! They mutually exclusive, and I don't have a firm opinion which one of them is correct.] Today I tried to improve the existing module-virtual-surround-sink (but the same issue also affects the IIR-based rewrite that is still sitting on my laptop). The problem is: the current normalization code does not do what it is designed to do. The module clips on some testcases. Let me copy-paste the problematic code for easy discussion. snip Thoughts? My thoughts: The scaling should be put in its own function with a comment that explains why the scaling is done, a high level description of how the scaling algorithm works, and a note that it's unclear whether the algorithm actually makes sense. Something like this could be included too: This algorithm doesn't pretend to be perfect, it's just something that appears to work (not too quiet, no audible clipping) on the material that it has been tested on. If you find a real-world example where this algorithm results in audible clipping, please write a patch that adjusts the scaling factor constants or improves the algorithm (or if you can't write a patch, at least report the problem to the PulseAudio mailing list or bug tracker). Would you like to write such a patch or should I do it? Or do you have an idea for a better heuristic? Regards, Ole ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] On scaling the HRIR in module-virtual-surround-sink
2014-04-02 1:48 GMT+06:00 Niels Ole Salscheider niels_...@salscheider-online.de: Would you like to write such a patch or should I do it? Or do you have an idea for a better heuristic? I do have an idea for a possibly-better heuristic (see below). However, I have caught a cold, and there is also an extraordinary number of DNS queries we (SafeDNS) get from Turkish users right now, leading to server load issues. So, my health and my work are priorities now :( So, please submit a patch. A possibly-better but untested heuristic is as follows, and I do intend to implement it later, after the Turkish YouTube/DNS situation settles. 1. Collect spectrum and inter-channel correlation data from some music DVDs, take an average. 2. Synthesize a short signal that has roughly the same characteristics. 3. Filter it through the A-weighing filter (see the transfer function in Wikipedia, it is a rational function = the filter is implementable as IIR). 4. Store the result as a short sequence of samples in PA source code. 5. When loading a filter from a wav file, apply it to the test signal from step (4). 6. Take the sum of squares of samples sent to the left headphone. This (due to A-weighing) would represent the subjective loudness of the filtered music. 7. Compare that to the sum of squares of samples sent through the conventional downmixer. Compensate accordingly by scaling the loaded filter. The result should be that the audio filtered through your module and through the conventional downmixer (in src/pulsecore/resampler.c), in average for the music material, would be of the same subjective loudness. I am not sure if that would be sufficient to eliminate the clipping, but we can always multiply the result by the fudge factor later if needed. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] On scaling the HRIR in module-virtual-surround-sink
On Sun, 2014-03-09 at 00:57 +0600, Alexander E. Patrakov wrote: Hello. [Do not blindly apply patches from this e-mail! They mutually exclusive, and I don't have a firm opinion which one of them is correct.] Today I tried to improve the existing module-virtual-surround-sink (but the same issue also affects the IIR-based rewrite that is still sitting on my laptop). The problem is: the current normalization code does not do what it is designed to do. The module clips on some testcases. Let me copy-paste the problematic code for easy discussion. snip Thoughts? My thoughts: The scaling should be put in its own function with a comment that explains why the scaling is done, a high level description of how the scaling algorithm works, and a note that it's unclear whether the algorithm actually makes sense. Something like this could be included too: This algorithm doesn't pretend to be perfect, it's just something that appears to work (not too quiet, no audible clipping) on the material that it has been tested on. If you find a real-world example where this algorithm results in audible clipping, please write a patch that adjusts the scaling factor constants or improves the algorithm (or if you can't write a patch, at least report the problem to the PulseAudio mailing list or bug tracker). So, I think the criteria for patches should be: does it fix audible clipping in real-world material without making the audio too quiet? -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] On scaling the HRIR in module-virtual-surround-sink
Hello Alexander, I wrote that module some time ago. And I had the same problems that you describe, i. e. when I tried to avoid clipping in the worst possible case, the output was way too quiet. Therefore I tried to come up with a heuristic and the 1.2 fudge factor seemed to work for me. But you are right that it depends on the HRIR and the content and I also came across situations in which there was clipping in the meantime. So this is definitely something that should be fixed. Kind regards, Ole ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] On scaling the HRIR in module-virtual-surround-sink
Hello.
[Do not blindly apply patches from this e-mail! They mutually exclusive,
and I don't have a firm opinion which one of them is correct.]
Today I tried to improve the existing module-virtual-surround-sink (but
the same issue also affects the IIR-based rewrite that is still sitting
on my laptop). The problem is: the current normalization code does not
do what it is designed to do. The module clips on some testcases. Let me
copy-paste the problematic code for easy discussion.
/* normalize hrir to avoid clipping */
hrir_max = 0;
for (i = 0; i u-hrir_samples; i++) {
hrir_sum = 0;
for (j = 0; j u-hrir_channels; j++)
hrir_sum += fabs(u-hrir_data[i * u-hrir_channels + j]);
if (hrir_sum hrir_max)
hrir_max = hrir_sum;
}
if (hrir_max 1) {
for (i = 0; i u-hrir_samples; i++) {
for (j = 0; j u-hrir_channels; j++)
u-hrir_data[i * u-hrir_channels + j] /= hrir_max * 1.2;
}
}
And here is where clipping (i.e. sum_left or sum_right becoming 1.0)
can happen:
sum_right = 0;
sum_left = 0;
/* fold the input buffer with the impulse response */
for (j = 0; j u-hrir_samples; j++) {
for (k = 0; k u-channels; k++) {
current_sample =
u-input_buffer[((u-input_buffer_offset + j) % u-hrir_samples) *
u-channels + k];
sum_left += current_sample * u-hrir_data[j *
u-hrir_channels + u-mapping_left[k]];
sum_right += current_sample * u-hrir_data[j *
u-hrir_channels + u-mapping_right[k]];
}
}
So, basically, here is the normalization logic: for each HRIR sample,
take the sum of all absolute values of HRIR channels at that time. Find
the maximum of these sums. Divide that factor out, with an extra fudge
factor of 1.2. Without the fudge factor, the corresponding explanation
in terms of the second code fragment is: if a single-sample click is
played simultaneously through all 5.1 channels, the output of the filter
(sum_left or sum_right) should just reach 1.0 at its maximum. With
hrir-kemar.wav from http://stuff.salscheider-online.de/hrir_kemar.tar.gz
(mentioned in the original submission), this logic (including the fudge
factor) divides the HRIR by 1.862.
What I don't understand is why simultaneous click in all input
channels is considered at all.
If the task is to avoid clipping even in the worst possible case, then
let's construct this worst possible case. Here are the instructions.
Take hrir-kemar.wav. Time-reverse it. Saturate all positive samples to
1.0 and all negative samples to -1.0. With this specially-constructed
sound, sum_left would at one point in time receive the sum of all
absolute values of all samples (in all channels) in the HRIR, so, that
is the value to divide out, and not what is written in the first code
fragment. I.e., this would be the patch (sorry if mangled, it is not
meant to be applied anyway):
--- a/src/modules/module-virtual-surround-sink.c
+++ b/src/modules/module-virtual-surround-sink.c
@@ -533,7 +533,7 @@ int pa__init(pa_module*m) {
const char *hrir_file;
unsigned i, j, found_channel_left, found_channel_right;
-float hrir_sum, hrir_max;
+float hrir_sum;
float *hrir_data;
pa_sample_spec hrir_ss;
@@ -759,20 +759,21 @@ int pa__init(pa_module*m) {
}
/* normalize hrir to avoid clipping */
-hrir_max = 0;
+hrir_sum = 0.0;
for (i = 0; i u-hrir_samples; i++) {
-hrir_sum = 0;
for (j = 0; j u-hrir_channels; j++)
hrir_sum += fabs(u-hrir_data[i * u-hrir_channels + j]);
+}
+
-if (hrir_sum hrir_max)
-hrir_max = hrir_sum;
+if (hrir_sum 0.01) {
+pa_log(hrir file is too quiet!);
+goto fail;
}
-if (hrir_max 1) {
-for (i = 0; i u-hrir_samples; i++) {
-for (j = 0; j u-hrir_channels; j++)
-u-hrir_data[i * u-hrir_channels + j] /= hrir_max * 1.2;
-}
+
+for (i = 0; i u-hrir_samples; i++) {
+for (j = 0; j u-hrir_channels; j++)
+u-hrir_data[i * u-hrir_channels + j] /= hrir_sum;
}
/* create mapping between hrir and input */
(Here I also removed the don't normalize quiet HRIRs logic, as I don't
understand its purpose and it had an obvious bug of not including the
fudge factor.)
Result: after this patch, the HRIR is divided by 24.339 and the module
indeed survives the worst possible testcase just without clipping. But
then, it becomes too quiet for normal use. That's why I don't want you
to apply the above patch.
The original code, even though it clips heavily in the worst possible
testcase, indeed produces no audible clipping on most (but not all!)
music DVDs that I tried, and I think that the correct problem to solve
here is indeed produce no audible clipping on typical content. So
there is some grain of truth in the
