Unless I’m mistaken, these dwc_otg parameters are for a kernel module, right? If that’s the case, lsmod shows just the Realtek wifi module loaded (8723bs), and all of these parameters are not making any difference? To wit, the fiq_split_enable=0 should summon a line to appear in the kernel log, which it definitely does not; in fact, there’s no FIQ related stuff in my dmesg output.
Anyway, I have very interesting news!
I’ve used dietpi-config to set the cpufreq governor to ‘performance’, and the clicks and pops stopped. I’ve enabled DSP in Roon to see how much it can take and it can do DSD64, 128 and for a while 256; this last one I think is limited by the network bandwidth over wifi, and I’m sure it would work just fine over a wired connection (playback just stops, isn’t scratchy or glitchy).
At this point, the CPU frequency was shown to be 1800MHz.
For some reason the CPU reached 64C and then I think some frequency scaling kicked in, and it went to 1608MHz. At this point, the clicks and pops returned when playing even 16/44100.
I proceeded to install cpufrequtils, and created /etc/default/cpufrequtils with the contents:
and rebooted. I did all this because I’ve no idea how dietpi-config sets the governor and how/if it’s persisted after reboot.
I’ve got a basic plastic case for the RPi3, and had placed the provided heatsink on the SOC.
With the case top off, it stays at 53-55C, 1800MHz playing 16/41000 without any issues; cpufreq-info reports it’s been at 1800MHz for 99.56% of the time, so no throttling to speak of.
Very interesting: I’ve manually dropped the frequency to 1608 MHz, and it still plays fine… I’ve further reduced it to 1GHz, and finally 408MHz, and it still plays fine… even DSD128, as in the attached image.
So whatever the CPU frequency governor “performance” does, it does well, and the frequency isn’t the key; it’s a power state setting, or something else that affects latency.