Possible fix for audio corruption on Dante route disconnect when using alsa/pipewire

[MeestorX]

Using pipewire and inferno sinks, whenever a dante route is made to that inferno channel, the audio starts cleanly. Whenever that route is disconnected, there would be some corruption of the audio and distortion for a second or so while the buffer empties.

With a little help from AI, I have a patch which fixes this for me. Sorry, but I'm not experienced enough to create a PR for this, but If this works for others experiencing this issue, then a PR should be made.

It silences the audio on a dante connection being removed rather than keeping the audio running while the buffer empties.

silence-on-disconnect.patch

--- a/inferno_aoip/src/ring_buffer.rs
+++ b/inferno_aoip/src/ring_buffer.rs
@@ -253,6 +253,19 @@ impl<T: Default + NoUninit, P: ProxyToBuffer<Atomic<T>>> RBInput<T, P> {
 
     self.rb.commit_readable_pos();
   }
+
+  /// Zero all samples in the underlying buffer and reset item_ready flags.
+  /// Used on Dante flow disconnect to prevent stale audio tail being read
+  /// by PipeWire before the SilenceWriter fills the buffer with zeros.
+  pub fn zero_all_samples(&mut self) {
+    self.rb.buffer.map(|buffer| {
+      for sample in buffer.iter() {
+        sample.store(T::default(), Ordering::Relaxed);
+      }
+    });
+    atomic::fence(Ordering::SeqCst);
+    self.item_ready = boolvec![false; self.rb.items_size];
+  }
 }
 
 /// Result of the `RBOutput::read_at` function.
--- a/inferno_aoip/src/device_server/flows_rx.rs
+++ b/inferno_aoip/src/device_server/flows_rx.rs
@@ -222,13 +222,14 @@ impl<P: ProxyToSamplesBuffer> FlowsReceiverInternal<P> {
             Command::DisconnectChannel { socket_index, channel_in_flow, rb_shared } => {
               if let Some(sd) = self.sockets[socket_index].as_mut() {
                 if let Some(ch) = sd.channels[channel_in_flow].as_mut() {
                   let sink_index_opt =
                     ch.sinks.iter().position(|sink| Arc::ptr_eq(sink.shared(), &rb_shared));
                   if let Some(sink_index) = sink_index_opt {
-                    let sink = ch.sinks.swap_remove(sink_index);
+                    let mut sink = ch.sinks.swap_remove(sink_index);
                     if let Some(now) = self.clock.wrapping_now_in_timebase(self.sample_rate.into()) {
+                      sink.zero_all_samples();
                       let rb_size = sink.ring_buffer_size();
                       let writer = SilenceWriter {
                         sink,
                         end_timestamp: now
                           .wrapping_add(rb_size + rb_size / 2 /*TODO: ???*/)
                           .wrapping_add_signed(ch.timestamp_shift),

[teodly]

I would prefer to fix the SilenceWriter since it was made for this.

Your approach with zeroing the entire buffer has an edge case: what if several seconds are buffered, the application is consuming data not-in-real-time on purpose (e.g. it was made to be CPU efficient), then, during this operation, samples before current timestamp may also be overwritten ( = lost, because they're not yet read by the app). SilenceWriter is designed to be synchronized with media clock for that very reason.

[MeestorX]

I would prefer to fix the SilenceWriter since it was made for this.

Sounds good to me. Is there a fix?

It's not perfect anyway, there's issues at 96k on low powered SBCs, and there's also distortion on startup, which I'm not sure if that's related.

[teodly]

Is there a fix?

I don't know why it doesn't work, but only sometimes, so not yet.

[MeestorX]

Ok, I've always had that corruption on unrouting, so if there's something I can test for you that might help, LMK.

[MeestorX]

I also have distortion and corruption on startup as pipewire is settling, if you have any suggestions about that?

[teodly]

Does the repeated buffer occur when you have several channels connected and disconnect only one of them?

I also have distortion and corruption on startup as pipewire is settling, if you have any suggestions about that?

This is normal if adaptive resampling is used. If not, it may be caused simply by system load during startup.

[MeestorX]

Does the repeated buffer occur when you have several channels connected and disconnect only one of them?

Yes, even with the fix. If I have only 2 Dante channels routed to inferno, I can disconnect one of them without corruption, but if I have 3 or more connected, even removing one will cause audible problems.
Same issue running at 96k, even with just 2 channels.

[teodly]

Does it depend on ALSA period size or PipeWire's api.alsa.headroom?

[teodly]

If I have only 2 Dante channels routed to inferno, I can disconnect one of them without corruption, but if I have 3 or more connected, even removing one will cause audible problems.
Same issue running at 96k, even with just 2 channels.

The sample rate influence points at performance/system jitter issue!

If that's the case, setting api.alsa.headroom to some sane value (non-zero of course) should help. Or set USE_FLOWS_CLOCK to 1 (ALSA plugin option, won't work from env var) and uncomment this:

inferno/inferno_aoip/src/device_server/flows_rx.rs

Line 405 in 3f2bf14

//self.current_timestamp.store(if now_ts!=usize::MAX { now_ts } else { usize::MAX-1 }, Ordering::Release);

Did you do cyclictest? The value measured by it should be a good starting point for api.alsa.headroom.

If that's the case, then... it is mostly stable when audio is running, because actual latency of received packets is usually much lower than configured RX latency, effectively contributing to the buffering headroom (as called in PipeWire). On the other hand, close_items_until is using current timestamp without latency correction.

[MeestorX]

This is pretty interesting. If I don't set api.alsa.period-xxx, they default to:

api.alsa.period-num = "32"
api.alsa.period-size = "1024"

WORSE or NO BETTER:

 api.alsa.period-num = "4"
 api.alsa.period-size = "8192"

api.alsa.period-num = "128"
api.alsa.period-size = "256"

api.alsa.period-num = "1024"
api.alsa.period-size = "32"

MUCH BETTER:

 api.alsa.period-num = "64"
 api.alsa.period-size = "16"

I thought I was going to get distortion with lower settings, but it actually seems work better!

[MeestorX]

Oh, api.alsa.headroom makes no difference in the disconnect ssue. Anything below 128 though causes audio distortion all the time, so I've left it at 256.

[MeestorX]

Did you do cyclictest? The value measured by it should be a good starting point for api.alsa.headroom.

I set it by trial and error. Latency is just set to 5ms as I'm not currently trying to go for lowest latency.

[MeestorX]

Looks like I can't set num and size any lower than 64/16.

Is there an issue with running it at these low values?