Why do I hear artifacts playing close to full digital scale files?

[dreamlayers]

I created a 10 kHz to 14 kHz mono sine wave sweep using sox -n sin.wav synth 6 sin 10k:14k. If I play this via Audacious, using either ALSA or PulseAudio, using either my motherboard audio or a USB audio device, I hear other frequencies beating with the sweep. I guess the sweep is being clipped, and then the resulting harmonics are being aliased via the sampling rate. I can use aplay, VLC or Chrome to play the file without this aliasing. I have no effect plugins enabled. Replay gain is disabled. So, I don't see why anything would be messing with the samples. Audacious should simply be sending the samples in the file as-is to the sound hardware, but it's not. To not hear artifacts, I need to decrease volume a tiny bit: sox -n sin2.wav synth 6 sin 10k:14k vol 0.97. I'm using Audacious 4.3.1-2.1build2 in Ubuntu 24.04.2 LTS.

Edit: Using the file writer plugin I created a WAV file where I can hear artifacts in every player I tried. Yet, surprisingly, the spectrogram in Audacity looks clean. Reducing the amplitude of the signal in Audacity makes the artifacts go away, so I guess the file doesn't contain artifacts. Instead, the artifacts seem to happen when playing a floating point WAV file. Maybe I hear artifacts on Audacious output because Audacious converts audio to floating point? When I convert it back to integer, sox warns me about clipped samples: "sox WARN sox: `sin.wav.wav' input clipped 32927 samples". Then if I open that in Audacity, the spectrum view shows the artifacts I'm hearing. This should only be the brightest line, the frequency sweep I generated, without all the other lines intersecting with it and reflecting.

[radioactiveman]

I don't know how the artifacts would sound like but on my system I can at least hear no difference between VLC and Audacious 4.4.2 with PipeWire or PulseAudio. Maybe the volume was too low but the sound is unpleasant for my ears.

Maybe I hear artifacts on Audacious output because Audacious converts audio to floating point?

@dreamlayers: Have you tried using integers as bit depth in the Audacious output settings?

@jlindgren90: Do you have ideas where the artifacts could be coming from? And which other Audacious settings could be related to this behavior?

[dreamlayers]

@radioactiveman My bit depth was set to "Automatic". Using any of the integer bit depths and floating point bit depth doesn't change this.

For me the artifacts are very easy to hear and I don't need to turn this up loud. But you don't need to listen to it. You can also look at the output on a spectrogram, or use the FileWriter plugin and look at the samples. With the bit depth set to Automatic, Audacious output floating point samples. Then it's easy to use sox to convert the file to integer and see clipping warnings.

$ sox -S sin.wav.wav -e signed-integer sin.wav-int.wav
sox WARN wav: wave header missing extended part of fmt chunk

Input File     : 'sin.wav.wav'
Channels       : 1
Sample Rate    : 48000
Precision      : 25-bit
Duration       : 00:00:06.00 = 288000 samples ~ 450 CDDA sectors
File Size      : 1.15M
Bit Rate       : 1.54M
Sample Encoding: 32-bit Floating Point PCM

In:100%  00:00:06.00 [00:00:00.00] Out:288k  [!=====|=====!]        Clip:32.9k
sox WARN sox: `sin.wav.wav' input clipped 32927 samples
Done.

It's also possible to dump the samples in the file. I don't know what tool exists for that so I made a small C program:

#include <stdio.h>

int main(void)
{
    FILE *f = fopen("sin.wav.wav", "rb");
    if (!f) return 1;
    if (fseek(f, 48, SEEK_SET) != 0) return 2;
    while (1) {
        float fl;
        if (fread(&fl, sizeof(fl), 1, f) != 1) break;
        printf ("%.20f\n", fl);
    }
    fclose(f);
    return 0;
}

Then running it shows the exact same number of clipped samples:

$ ./foo | egrep '^-?1\..*[^0]' | wc
  32927   32927  773740

Here is some example output direct from the program

1.00410211086273193359
0.04923527687788009644
-0.97735756635665893555
-0.55396878719329833984
0.69147896766662597656
0.91240137815475463867
-0.21896964311599731445
-1.02565538883209228516
-0.31191343069076538086
0.86413937807083129883
0.75907659530639648438
-0.47134310007095336914
-1.00307834148406982422

There should be no numbers below -1 and above +1 present, but they are present.

[dreamlayers]

I had the equalizer turned on. Turning it off fixed the problem.

I never use the equalizer. I thought I had it turned off, and it wasn't visible, so I didn't know I had it turned on. Also, in the Winamp classic interface it is hard to see if everything is set to the middle. I thought everything was set to the middle, but careful investigation showed that one of the bands was a tiny bit above the middle. There should be a one pixel dotted line showing only. In the GTK interface there are numbers below the sliders and those can easily be set to zero. After setting all equalizer values to 0, the problem went away, even when the equalizer was turned on.

So, it seems the equalizer can very easily generate clipping. If turning up any of the bands, one needs to turn down the preamp to avoid clipping. There seems to be no automatic protection against clipping.

Edit: I'm not able to create these "aliasing of harmonics" artifacts using Winamp 5.8 build 3660. Allowing users to mangle their sound so easily, without the application helping the user to avoid clipping or notifying about clipping, could be seen as a bug. Though since I never use the equalizer it is not important to me.