Audio Phantom Sound - 4 kHz + 6 kHz

[rene]

Oh, it's certainly by design, although I'd personally feel it in this specific case still turns out as a bug, realistically speaking. There's (of course) information out there as to limiting versus clamping mixing algorithms. F.e. https://dsp.stackexchange.com/questions ... t-clipping

Windows clearly choosing a more involved method does mean that certainly Pulseaudio's (and, again, ALSA's) choice is not a given. If you'd feel it interesting you'd go ask/argue the case at https://gitlab.freedesktop.org/pulseaud ... dio/issues. Certainly you have a very clear example of a detrimental effect. If you do, please post back a link to the issue...

[Dampi05]

I've made a bug report on their gitlab page:
https://gitlab.freedesktop.org/pulseaud ... issues/671

I've also linked from there back to this post, hopefully the issue will be solved.

[rene]

Interesting, but do note that the report is seemingly not fully correct. I.e., we apparently aren't here so much talking about an "expected" and mathematically relatively clear combination tone, but a mathematically difficult to analyse result of clamping by the mixing algorithm in Pulseaudio.

In the above discussion the original "sines.c" versus the later "clamps.c" shows the issue most directly programmatically, of course while noting that the "clamps.c" effect is what is noticed also with Pulse's own mixing (and, in fact, as seen to BE its algorithm from some light reading of the Pulseaudio source I did).

[rene]

In case the gitlab reports attracts readers; for convenience again sines.c and clamps.c respectively:

sines.c:

Code: Select all

/* gcc -W -Wall -O2 $(pkg-config --cflags libpulse-simple) -o sines sines.c -lm $(pkg-config --libs libpulse-simple) */

#include <stdlib.h>
#include <stdint.h>
#include <math.h>

#include <pulse/simple.h>

#define FREQ1 4000
#define FREQ2 6000

#define RATE 44100
#define SECS 10

int16_t samples[RATE];

static const pa_sample_spec spec = {
	.format		= PA_SAMPLE_S16NE,
	.rate		= RATE,
	.channels	= 1,
};

int main(void)
{
	int i;
	double x, y;

	for (i = 0, x = 0, y = 0; i < RATE; i++, x += (2 * M_PI * FREQ1) / RATE, y += (2 * M_PI * FREQ2) / RATE)
		samples[i] = (INT16_MAX * (sin(x) + sin(y))) / 2;

	pa_simple *s = pa_simple_new(NULL, "sines", PA_STREAM_PLAYBACK, NULL, "sines", &spec, NULL, NULL, NULL);
	if (!s) 
		return EXIT_FAILURE;

	for (i = 0; i < SECS; i++)
		pa_simple_write(s, samples, sizeof(samples), NULL);

	pa_simple_drain(s, NULL);
	pa_simple_free(s);

	return EXIT_SUCCESS;
}

clamps.c:

Code: Select all

/* gcc -W -Wall -O2 $(pkg-config --cflags libpulse-simple) -o clamps clamps.c -lm $(pkg-config --libs libpulse-simple) */

#include <stdlib.h>
#include <stdint.h>
#include <math.h>

#include <pulse/simple.h>

#define FREQ1 4000
#define FREQ2 6000

#define RATE 44100
#define SECS 10

int16_t samples[RATE];

static const pa_sample_spec spec = {
	.format		= PA_SAMPLE_S16NE,
	.rate		= RATE,
	.channels	= 1,
};

int main(void)
{
	int i;
	double x, y;

	for (i = 0, x = 0, y = 0; i < RATE; i++, x += (2 * M_PI * FREQ1) / RATE, y += (2 * M_PI * FREQ2) / RATE) {
		int32_t sample = INT16_MAX * (sin(x) + sin(y));
		samples[i] = sample < INT16_MIN ? INT16_MIN : sample;
		if (sample > INT16_MAX)
			samples[i] = INT16_MAX;
	}

	pa_simple *s = pa_simple_new(NULL, "sines", PA_STREAM_PLAYBACK, NULL, "sines", &spec, NULL, NULL, NULL);
	if (!s) 
		return EXIT_FAILURE;

	for (i = 0; i < SECS; i++)
		pa_simple_write(s, samples, sizeof(samples), NULL);

	pa_simple_drain(s, NULL);
	pa_simple_free(s);

	return EXIT_SUCCESS;
}

[Dampi05]

Can you check if it's more accurate now?

[rene]

Yes, that would be a proper report now. Curious as to replies...

[Dampi05]

It seems as though the thread has been closed quoting this:

Next going straight to ALSA rather than through Pulseaudio -- still same, and including without any resampling taking place.

[MrEen]

The person is saying rene's post shows the issue appears when using ALSA directly, bypassing pulseaudio. Therefore, it's not a pulseaudio bug.

[Dampi05]

Yes, I see that, just wanted to verify this was definitely the case, since it would obviously mean I need to post an issue to the ALSA team and not PulseAudio team

[MrEen]

From my reading of rene's post, the ALSA team would be the correct choice.

Correction: It may be the kernel team: https://www.alsa-project.org/wiki/Bug_Tracking

[rene]

No, the fact that ALSA's dmix also shows the same behaviour just means that ALSA's dmix and Pulseaudio use the same clamping algorithm. Pulseaudio mixes itself: does NOT go through ALSA's dmix. So, no, you definitely need to be at Pulseaudio here since it's suggested that Pulseaudio changes it's mixing algorithm, as a matter of configuration at least. To be very precise, this is where this Pulseaudio behaviour originates in this specific case: https://github.com/pulseaudio/pulseaudi ... mix.c#L125

And as said, calling it a "bug" may be overdoing it with some people considering clamping to be a valid algorithm, but I'd note the comments in that above linked dsp thread, https://dsp.stackexchange.com/questions ... t-clipping, where people are basically calling anything but my original "/ 2" approach flat-out wrong.

I'd reopen, quoting the above part of this reply. But I will also note that lots of experience with similar success on open-source bugzilla's kept me from pursuing the matter myself in the first place. You need to be... patient.

[Dampi05]

Yes, I can be very persistent, I intend on eventually getting this fixed.

You may find the responses on https://gitlab.freedesktop.org/pulseaud ... issues/671 interesting, the guy has pointed out the same thing and re-opened it stating that ALSA dmix is at least part of the problem. He'll send me a test to run for PulseAudio without ALSA (or at least close enough to that) to verify if it's just dmix or not, but as it seems, it's probably part of both.

I'll wait with the conclusion though since I can't be certain.

[rene]

I'd point him to that https://github.com/pulseaudio/pulseaudi ... mix.c#L125 link, i.e., to Pulseaudio source. Moreover, unless something very, very fundamentally changed while I wasn't paying attention (i.e., the last 10 years or so) then as said, Pulseaudio does not even use ALSA's dmix. This is to say that ALSA dmix tests would be utterly irrelevant from a Pulseaudio perspective. Sure, ALSA dmix apparently uses a clamping algorithm also -- but I'm sure that e.g. "sox" or "audacity" could as well. That's however exactly as irrelevant to Pulseaudio's algorithm as ALSA's dmix is.

[rene]

Following the conversation on gitlab, but do note it might not be an easy change. Specifically if Pulseaudio currently has just the one mixing algorithm rather than a plugin-like infrastructure (I do not in fact know, but assume that if it had it would've already been put to use) then changing this would be a relatively major refactoring.

Also, while DSP-purists seem to agree with my initial naive /2 algorithm the reason I called it naive is due to the same reason the initial post in that dsp thread does; it being rather debatable to halve amplitude of the sources. And come to think of it for a general mixing algorithm such as Pulseaudio's, what are you going to do with 50 to be mixed sources? Dividing amplitude by 50 is practically speaking impossible. So you're very quickly looking at fairly involved dynamic compressor techniques to keep this doable at all, which, while I'm not an expert, will very likely need look-ahead to perform even halfway reasonable. I.e., non-realtime, i.e., add latency.

I believe the thing to do would be figuring out what e.g. Windows and/or Mac does, because my suggestion really is too naive for a general purpose mixing implementation. I have not a clue as to either system...