I2S data stream format

Question

While I'm working with RPi I2S and couple of DACs, I notice something which I like to verify in here.

When I connect the scope to I2S interface I usually see waveforms similar to this:

In here 1st channel is connected to BCK, 2nd is connected to LRCK and 3rd is connected to DOUT.

In here I noticed no data in DOUT and it is accepted because I'm not playing anything.

To verify the I2S functionality I generate 2 channel MP3 and 16-bit PCM WAV clips from Audacity which contains only 3 minutes of silence. When I play these clips I notice some data in DOUT.

My problem is why I'm seeing data for these "silent" audio streams? Why I'm not getting 0 for silence?

When I connect this output to 24bit DAC I heard this as noise in high volumes. Is this is due to some misconfiguration of my device-tree overlay, or any other configuration issue?

This is the device-tree overlay and asound.conf which I used for testing:

/dts-v1/;
/plugin/;

/ {
    fragment@0 {
            target = <&i2s>;
            __overlay__ {
                    #sound-dai-cells = <0>;
                    status = "okay";

                    cpu_port: port {
                            cpu_endpoint: endpoint {
                                    remote-endpoint = <&codec_endpoint>;
                                    dai-format = "i2s";
                                    dai-tdm-slot-num = <2>;
                                    dai-tdm-slot-width = <24>;
                                    bitclock-master;
                                    frame-master;
                            };
                    };
            };
    };

    fragment@1 {
            target-path = "/";
            __overlay__ {
                    spdif-transmitter {
                            #address-cells = <0>;
                            #size-cells = <0>;
                            #sound-dai-cells = <0>;
                            compatible = "linux,spdif-dit";
                            status = "okay";

                            codec_port: port {
                                    codec_endpoint: endpoint {
                                            remote-endpoint = <&cpu_endpoint>;
                                    };
                            };
                    };
            };
    };

    fragment@2 {
            target = <&sound>;
            __overlay__ {
                    compatible = "audio-graph-card";
                    label = "GenericLJ";
                    dais = <&cpu_port>;
                    status = "okay";
            };
    };

};

asound.conf:

pcm.speakerbonnet {
   type hw card 0
}

pcm.dmixer {
   type dmix
   ipc_key 1024
   ipc_perm 0666
   slave {
     pcm "speakerbonnet"
     period_time 0
     period_size 1024
     buffer_size 8192
     rate 44100
     channels 2
   }
}

ctl.dmixer {
    type hw card 0
}

pcm.softvol {
    type softvol
    slave.pcm "dmixer"
    control.name "PCM"
    control.card 0
}

ctl.softvol {
    type hw card 0
}

pcm.!default {
    type             plug
    slave.pcm       "softvol"
}

Answer 1

Because windows using data dithering. So the 0 is not zero but -1; -2; 0; 1; 2;

Answer 2

I wouldn't trust a lossy format such as MP3 to represent a signal with 100% accuracy. Even if the original signal you encoded was absolute silence, it may no longer be the case after MP3 encoding due to rounding errors, filtering artifacts, etc.

For PCM files it's easy to check if the data stream is filled with zeroes or not. Unless you're 100% sure you're outputting nothing but zeroes, I wouldn't suspect the noise comes from your HW configuration.

Answer 3

I can't see where the file is read in your code, but is it possible that the 16 bit file actually contains a little noise so you get 0 and -1, and then you aren't converting from 16 to 24 bits correctly so the FIFO is seeing these numbers not aligned ? My reasoning is I think the short spikes are +1, the gaps 0 and the all high -1, but not correctly aligned. Just a guess though.