Hello guys, wow this is overwhelming, thanks for all the answers and comments, but please, don't take it too seriously, I feel bad wasting your time for a 24 euros dac!
So I tried the black USB port as well and compared with the blue one: I listened to the same 7:51 minutes long song with the dac connected to each port and the pi freshly restarted each time. I counted the glitches I could hear in each case. Might be I missed some if they were less audible, but these were definitely there:
Blue USB: 8 glitches
Black USB: 12 glitches
To put it in perspective, in the zero you get one every 3-4 seconds.
Regarding the second test, I will have to do some research to do it, but I promise I will.
Thanks again!
Try bumping the kernel.
The command below installs latest kernel committed to the Pi firmware repo and automatically deletes old kernel modules so some disk space can be reclaimed.
sudo PRUNE_MODULES=1 rpi-update
Heres some useful links.
Commits * Hexxeh/rpi-firmware * GitHub
GitHub - Hexxeh/rpi-update: An easier way to update the firmware of your Raspberry Pi
The command below installs latest kernel committed to the Pi firmware repo and automatically deletes old kernel modules so some disk space can be reclaimed.
sudo PRUNE_MODULES=1 rpi-update
Heres some useful links.
Commits * Hexxeh/rpi-firmware * GitHub
GitHub - Hexxeh/rpi-update: An easier way to update the firmware of your Raspberry Pi
Very good. It looks like some problem with the VL805, fixed in later kernels.
That parameter limits speed of the USB interface to fullspeed (12Mbps). That's not what you want because your DAC is highspeed (480Mbps). Can you just load the dwc_otg module without any params?
Just boot your Zero, connect via ssh over wireless (no USB dependence), check whether either dwc2 or dwc_otg modules are loaded (lsmod). If dwc2 is loaded, rmmod dwc2. Then modprobe dwc_otg (if not loaded yet), check dmesg, connect your soundcard (while watching dmesg for info) and see if it helps.
That parameter limits speed of the USB interface to fullspeed (12Mbps). That's not what you want because your DAC is highspeed (480Mbps). Can you just load the dwc_otg module without any params?
Just boot your Zero, connect via ssh over wireless (no USB dependence), check whether either dwc2 or dwc_otg modules are loaded (lsmod). If dwc2 is loaded, rmmod dwc2. Then modprobe dwc_otg (if not loaded yet), check dmesg, connect your soundcard (while watching dmesg for info) and see if it helps.
So I run lsmod and neither of them (dwc2 nor dwc_otg) was listed so I input modprobe dwc_otg and I must say it helped a lot!
It is not yet perfect like the pi4 yet but well, it is listeneable, while before it was not.
Thanks a lot, I have no idea what all that means, but I am a results oriented guy haha
It is not yet perfect like the pi4 yet but well, it is listeneable, while before it was not.
Thanks a lot, I have no idea what all that means, but I am a results oriented guy haha
MRanome, great to hear the improvement.
IMO the problem is the single core of Pi Zero combined with relatively high CPU demands of the dwc IP core and bInterval=1 used by your DAC's USB receiver.
USB2 microframe has a period of 125us. bInterval=1 tells the USB host that every microframe is used for the audio data, even though only maximum of 384bytes is used out of the 1024 bytes per packet available for isochronous transfer by the USB2 specs. 384 bytes are for the 32bit audio format, the more practical 24bit format takes comparably less - 288 bytes. The bInterval=1 is widely used by DAC manufacturers as it offers the smallest latency (only 125us max delay on the bus), in exchange for more work by the USB host. On the other hand even the 32bit format could be served by sending 768 bytes every 250us (bInterval=2), cutting the number of packets sent by half to 4k.
Now properly-designed USB controllers have no problem with sending/receiving data every 125us as they read/write the data to RAM via DMA and the CPU does not have to process every 125us microframe separately, processes them in multiples.
The dwc IP core USB controller uses DMA too but sends an interrupt request to the CPU every 125us. There are several types of interrupt requests on ARM, standard IRQs and higher-priority so called "fast" FIQs. The dwc2 driver does not use the FIQs, reducing the USB host performance. The more complicated dwc_otg driver implements the FIQ support. Still the CPU must serve all the interrupts (i.e. 8k interrupts per second for the bInterval=1 USB device) and one core can miss some when it has to do all the other work.
My 2 cents the new Rpi Zero 2 with the four ARM cores (and the same dwc IP core) may alleviate this problem.
IMO the problem is the single core of Pi Zero combined with relatively high CPU demands of the dwc IP core and bInterval=1 used by your DAC's USB receiver.
USB2 microframe has a period of 125us. bInterval=1 tells the USB host that every microframe is used for the audio data, even though only maximum of 384bytes is used out of the 1024 bytes per packet available for isochronous transfer by the USB2 specs. 384 bytes are for the 32bit audio format, the more practical 24bit format takes comparably less - 288 bytes. The bInterval=1 is widely used by DAC manufacturers as it offers the smallest latency (only 125us max delay on the bus), in exchange for more work by the USB host. On the other hand even the 32bit format could be served by sending 768 bytes every 250us (bInterval=2), cutting the number of packets sent by half to 4k.
Now properly-designed USB controllers have no problem with sending/receiving data every 125us as they read/write the data to RAM via DMA and the CPU does not have to process every 125us microframe separately, processes them in multiples.
The dwc IP core USB controller uses DMA too but sends an interrupt request to the CPU every 125us. There are several types of interrupt requests on ARM, standard IRQs and higher-priority so called "fast" FIQs. The dwc2 driver does not use the FIQs, reducing the USB host performance. The more complicated dwc_otg driver implements the FIQ support. Still the CPU must serve all the interrupts (i.e. 8k interrupts per second for the bInterval=1 USB device) and one core can miss some when it has to do all the other work.
My 2 cents the new Rpi Zero 2 with the four ARM cores (and the same dwc IP core) may alleviate this problem.
Last edited:
From what I read moode requires just adding the new board IDs in order to use the 64bit kernel Pi Zero 2 W . IMO no reason for camilladsp not to run as it runs great on any Pi, both 32bit and 64bit. I am really interested in your results, thanks.
The issue you face with the dwc controller is not unusual, there are more people having problems with highspeed bInterval=1 DACs on the dwc controller, typically using the better-known dwc2 driver.
Thanks, but that's all due to having available all the source code and direct access to the huge know-how of USB specialists on linux mailing lists. Some of them even serve on the USB specs committee. And of course being able to test the latest code on an affordable HW, and being able to upgrade to the latest kernel with the patches with a simple command for the users. That's what makes the RPi the king, despite its many many flaws.
Of course being expected to support any DAC in the world out of the box is much more difficult (and often leading to disappointment) than integrating a selected DAC into one package (and using I2S instead of USB at best), as we've already talked about it. That's always a safer and better option for the vendor as well as for non-DIY consumers.