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:
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?)
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 startedspam 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:
The following two env vars seem to help. Some apps don't seem to care about the pipewire one, so I'm setting both:
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?)