Loud popping due to sample set to -1

[ArviFoxy]

Hi,

I'm trying to use roc for streaming over wifi, hoping to achieve lower latency than my previous snapcast setup. It works well except that it sometimes produces an extremely loud popping sound. I've recorded the output using the following setup:

spotify -> pipewire -> roc-send -> wifi -> roc-recv -> pipewire loopback

The output contains a sample set to -1.0 (or -32768 s16) that causes the popping (see the screenshot and attached wav):

Nothing like this happens on snapcast using the same devices and pipewire setup. As far as I understand dropped packets would result in samples set to 0, so this looks more like some kind of memory error / uninitialized value?

I haven't caught the exact moment in the logs unfortunately. The one thing that stands out to me in the logs is that the number of lost packets also gets set to -32768 at some point ("packets(lost/exp)"):

18:40:14.332 [3587] [dbg] roc_rtp: timestamp injector: received mapping: old=cts:0/sts:0 new=cts:1736530814330182960/sts:3819408770 has_ts=0 n_drops=0                                                        
18:40:14.332 [3587] [dbg] roc_audio: watchdog: status: wwwwwwww............                            
18:40:19.313 [3587] [dbg] roc_audio: latency tuner: e2e_latency=976(22.132ms) niq_latency=432(9.796ms) target_latency=573(12.993ms) stale=112(2.540ms) packets(lost/exp)=0/3448 jitter(mean/peak)=1.649ms/7.230ms fec_blk=8.707ms fe=0.999813 eff_fe=0.999813 fe_stbl=false                                          
18:40:21.220 [3587] [dbg] roc_netio: udp port: <udp 0x7FFEB8001468 bind=0.0.0.0:10003>: recv=901 send=901 send_nb=901                                                                                         
18:40:22.021 [3587] [dbg] roc_sndio: pulseaudio sink: io_latency=258(5.850ms)                          
18:40:24.314 [3587] [dbg] roc_audio: latency tuner: e2e_latency=961(21.791ms) niq_latency=512(11.610ms) target_latency=573(12.993ms) stale=54(1.224ms) packets(lost/exp)=0/6895 jitter(mean/peak)=1.630ms/7.230ms fec_blk=8.707ms fe=0.999871 eff_fe=0.999871 fe_stbl=false                                          
18:40:29.312 [3587] [dbg] roc_audio: latency tuner: e2e_latency=1048(23.764ms) niq_latency=464(10.522ms) target_latency=573(12.993ms) stale=25(0.567ms) packets(lost/exp)=0/10338 jitter(mean/peak)=1.627ms/7.230ms fec_blk=8.707ms fe=0.999883 eff_fe=0.999883 fe_stbl=false 

...

18:42:14.317 [3587] [dbg] roc_audio: depacketizer: period=30000.54ms missing=9.80ms(0.033%) late=9.80ms
(0.033%) recovered=0.00ms(0.000%)                                                                      
18:42:14.337 [3587] [dbg] roc_rtp: timestamp injector: received mapping: old=cts:1736530934132045759/sts:3824690421 new=cts:1736530934332328743/sts:3824699236 has_ts=1 n_drops=0                             
18:42:19.315 [3587] [dbg] roc_audio: latency tuner: e2e_latency=1310(29.705ms) niq_latency=624(14.150ms) target_latency=573(12.993ms) stale=63(1.429ms) packets(lost/exp)=-32768/53369 jitter(mean/peak)=1.657ms/8.880ms fec_blk=8.707ms fe=1.000001 eff_fe=1.000001 fe_stbl=true                                    
18:42:21.222 [3587] [dbg] roc_netio: udp port: <udp 0x7FFEB8001468 bind=0.0.0.0:10003>: recv=1501 send=1501 send_nb=1501                                                                                     
18:42:22.020 [3587] [dbg] roc_sndio: pulseaudio sink: io_latency=258(5.850ms)                          
18:42:24.316 [3587] [dbg] roc_audio: latency tuner: e2e_latency=1315(29.819ms) niq_latency=592(13.424ms) target_latency=573(12.993ms) stale=63(1.429ms) packets(lost/exp)=-32768/56815 jitter(mean/peak)=1.657ms/8.880ms fec_blk=8.707ms fe=1.000001 eff_fe=1.000001 fe_stbl=true                                    
18:42:27.111 [3587] [dbg] roc_audio: freq estimator: unstable, 0 > 64 / 573                            
18:42:29.314 [3587] [dbg] roc_audio: latency tuner: e2e_latency=1313(29.773ms) niq_latency=672(15.238ms) target_latency=573(12.993ms) stale=65(1.474ms) packets(lost/exp)=-32768/60260 jitter(mean/peak)=1.657ms/8.880ms fec_blk=8.707ms fe=1.000035 eff_fe=1.000035 fe_stbl=false                                   
18:42:32.019 [3587] [dbg] roc_rtcp: rtcp communicator: generated_pkts=150 processed_pkts=150 proc_errs=0                                                                                                      
18:42:32.022 [3587] [dbg] roc_sndio: pulseaudio sink: io_latency=257(5.828ms)                          
18:42:34.315 [3587] [dbg] roc_audio: latency tuner: e2e_latency=1338(30.340ms) niq_latency=640(14.512ms) target_latency=573(12.993ms) stale=69(1.565ms) packets(lost/exp)=-32768/63706 jitter(mean/peak)=1.659ms/8.880ms fec_blk=8.707ms fe=1.000053 eff_fe=1.000053 fe_stbl=false                                   
18:42:39.316 [3587] [dbg] roc_audio: latency tuner: e2e_latency=1296(29.388ms) niq_latency=672(15.238ms) target_latency=573(12.993ms) stale=71(1.610ms) packets(lost/exp)=-32768/67152 jitter(mean/peak)=1.658ms/8.880ms fec_blk=8.707ms fe=1.000035 eff_fe=1.000035 fe_stbl=false

Context

It's running on raspberry pi 5, arm64 using the dev branch @264c175b5ce and commands:

Receiver:

$ roc-recv -vv --output=pulse://loopback_input.recoding -s rtp+rs8m://0.0.0.0:10001 -r rs8m://0.0.0.0:10002 -c rtcp://0.0.0.0:10003 --target-latency=13ms  --packet-encoding=101:pcm@s16/44100/mono --io-encoding=pcm@s16/44100/mono --io-latency=1.45ms --io-frame-len=1.45ms

Sender:

roc-send -vv --input=pulse://mix_output.stereo_to_mono --io-encoding=pcm@s16/44100/mono --io-latency=1.45ms --io-frame-len=1.45ms -s rtp+rs8m://center-speaker.local:10001 -r rs8m://center-speaker.local:10002 -c rtcp://center-speaker.local:10003 --packet-encoding=101:pcm@s16/44100/mono --packet-len=1.45ms --fec-block-src=6 --fec-block-rpr=4

I have also tried to set the latency to be much longer (~60ms) with longer FEC block but that did not solve the issue.

Recording (wav):

roc-6-4-default-resampler.zip

[ArviFoxy]

This also happens in each of these scenarios:

• With FEC disabled (just RTP).
• Using the master branch.
• When playing silence.

[gavv]

Thanks a lot for detailed report! Will take a look into it.

[ArviFoxy]

The issue does not happen with the resampler set to speexdec on the receiver (instead of auto). I've recorded >1 hour with no problems.

The only references to "= -1" in the code base I could find is clamping to Sample_Min, so it's likely a sample <1 (from the built-in resampler?) getting clamped:

roc-toolkit/src/internal_modules/roc_audio/mixer.cpp

Line 132 in 3a19267

out_data[n] = std::max(out_data[n], Sample_Min);

[pwaller]

For reference, I also encountered this without realising the likely source and filed commented on an issue against pipewire. https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4516

[pwaller]

For what it's worth as a data point, I just did an experiment involving:

roc-send \
    --resampler-profile=high \
    -s rtp+rs8m://127.0.0.1:20001 \
    -r rs8m://127.0.0.1:20002 \
    -c rtcp://127.0.0.1:20003 \
    -i "file:$INPUT_FILE"

ip netns exec "$NS_NAME" roc-recv \
    -s rtp+rs8m://127.0.0.1:20001 \
    -r rs8m://127.0.0.1:20002 \
    -c rtcp://127.0.0.1:20003 \
    -o "file:$OUTPUT_FILE" \
    --output-format wav

And generated ~hours of output, which had no clicks.

However, using the same version of roc with pipewire, I was able to generate this large negative sample (around 2 minutes in to a 10 minute clip). The sample value in the debug capture I have from pipewire is -633736030000000000000000000000 which python tells me is -0x1.ffed8a145aaf2p+98 in hex, which just looks like a large negative sample (the rest of the samples are in range -1 to +1 as expected). For my test setup I had pipewire running in network namespace using the loopback interface with some artifical delay and packetloss with tc qdisc change dev lo root netem delay 1000ms 5ms loss 2% corrupt 1% reorder 1%.

This datapoint leads me to wonder if the issue is somewhere in the pipewire integration, or exposed by pipewire, rather than with roc specifically.

My pipewire config is something like:

  { name = libpipewire-module-roc-source
    args = {
      local.ip = "127.0.0.1"
      local.source.port = 20001
      local.repair.port = 20002
      local.control.port = 20003
      resampler.profile = high
      fec.code = rs8m
      sess.latency.msec = 25
      source.name = "ROC Source"
      source.props = {
        node.name = "roc-source"
        audio.rate = 48000
        audio.quantum = 128
        audio.format = "S16LE"
      }
    }

and the debug stream was captured via pw-cli s roc-source Props '{ params = [ debug.wav-path "'$PWD/capture-roc-source.wav'" ] }'