J314 speaker DSP pops/crackles when seeking YouTube videos unless filter node suspend is disabled

[itsDNNS]

Summary

On a MacBook Pro 14" M1 Pro (J314), the internal speaker DSP path produces an audible pop/crackle when seeking/skipping in YouTube videos. The issue does not occur when using AirPods over Bluetooth, and it also does not appear with a local test video in ffplay/mpv, which points to the internal audio_effect.j314-convolver path rather than the browser or general PipeWire output.

Disabling idle pause/suspend for the J314 convolver filter appears to eliminate the issue.

System

• Device: Apple MacBook Pro (14-inch, M1 Pro, 2021)
• OS: Fedora Linux Asahi Remix 44 KDE
• Kernel: 6.19.13-400.asahi.fc44.aarch64+16k
• asahi-audio: 3.4-5.fc44
• alsa-ucm-asahi: 8-4.fc44
• speakersafetyd: 1.0.2-7.fc44
• PipeWire: 1.6.4-1.fc44
• WirePlumber: 0.5.14-1.fc44

Reproduction

1. Use internal speakers, default sink: audio_effect.j314-convolver
2. Play a YouTube video in Firefox or Chromium.
3. Seek/skip forward or backward in the video.
4. A short audible pop/crackle is heard immediately around the seek.

Observations

• Happens in both Firefox and Chromium.
• Does not happen with AirPods over Bluetooth.
• Local playback/seek test with ffplay/mpv did not reproduce the same crackle.
• PipeWire/WirePlumber logs repeatedly show messages like:

spa.filter-graph: graph has unaligned latency min:7680.000000 max:8160.000000
spa.filter-graph: output port 0 from copyLW min:8160.000000 max:8160.000000
spa.filter-graph: output port 2 from convLT min:7680.000000 max:7680.000000

Workaround

Adding the following properties to /usr/share/asahi-audio/j314/graph.json for both capture.props and playback.props appears to eliminate the pop/crackle:

"node.pause-on-idle": "false",
"session.suspend-timeout-seconds": 0

After restarting PipeWire/WirePlumber and using the internal speakers again, seeking in YouTube no longer produces the audible crackle.

Question

Should the J314 speaker DSP filter-chain avoid pause/suspend by default, or is there a better place to prevent this transient when the graph resumes after short stream interruptions?