Description
Some applications/websites like discord request a lower latency when they start the audio device, I think this means that a smaller buffer is prepared. This seems to cause that aaudio_pcm_pointer while not started
spam in dmesg. I'm guessing when it starts up the audio it runs out of buffer during the turning-on-speaker process and this causes the popping/repeated-turning-off-and-on-speaker noises.
I was able to narrow this down by comparing pipewire logs between discord (causes the issue) and youtube (doesn't cause the issue) and then testing changing the latency with aplay:
# this one is ok for me
dd if=/dev/zero bs=1k count=1 | PIPEWIRE_LATENCY=2048/48000 aplay -
# this one makes the noise and interrupts audio
dd if=/dev/zero bs=1k count=1 | PIPEWIRE_LATENCY=128/48000 aplay -
The following two env vars seem to help. Some apps don't seem to care about the pipewire one, so I'm setting both:
PULSE_LATENCY_MSEC=120
PIPEWIRE_LATENCY=2048/48000
That might increase latency a bit, but its better than having audio stop working for some applications. The speakers seemed ok with 256/48000, but 128 was too little for them. It still does sometimes have the issue (e.g. when switching between speakers and headphones, and opening pavucontrol), so this is by no means a complete solution.
There might be a way to get apple-bce audio to report the minimum latency it supports, I grepped for latency in the code and it seems to ask the ARM side for the global, input and output latencies but I haven't investigated much further. (maybe the units for those are wrong or something similar?)