RPi devs have released their patched 5.18 candidate https://github.com/raspberrypi/linux/tree/rpi-5.18.y
I tried building with RPi's 5.18.y branch and so far no luck.
I get this with a clean install:
Using the latest build of the 5.17.y branch on the same configuration of my RPi at least loads the driver though Windows 11 doesn't seem to like it as a output device. It only accepts it as an input (from my limited testing).
Any pointers on how to fix this or should I just wait for rc2?
Anyways, looking forwards to your upcoming patches.
I get this with a clean install:
Code:
pi@rpi-z2w:~ $ dmesg | grep -iE "g_audio|dwc2"
[ 4.748489] UDC core: couldn't find an available UDC - added [g_audio] to list of pending driversUsing the latest build of the 5.17.y branch on the same configuration of my RPi at least loads the driver though Windows 11 doesn't seem to like it as a output device. It only accepts it as an input (from my limited testing).
Any pointers on how to fix this or should I just wait for rc2?
Anyways, looking forwards to your upcoming patches.
The latest rpi 5.18.y branch still has this problem, dwc2 does not start up at all. There have been many rpi-specific patches submitted to this branch by the rpi team in the previous days, maybe this branch is not finished by them yet. I just asked about the issue, will see the response https://github.com/raspberrypi/linux/issues/4992 . Thanks for the testing.
Masonrf - please can you test my dwc2 bugfix at https://github.com/raspberrypi/linux/issues/4992#issuecomment-1100070149 ? Thanks.
I can confirm that this patch fixes the problem. It also fixes some bugs from the previous versions of the kernel that I have been experiencing. Good work!
From my limited testing, I currently have the best luck when setting values in /etc/modprobe.d/g_audio.conf , uninstalling the device from Windows device manager, and rebooting the Pi to change paramters, but it seems to be working with multiple sample rates!
From my limited testing, I currently have the best luck when setting values in /etc/modprobe.d/g_audio.conf , uninstalling the device from Windows device manager, and rebooting the Pi to change paramters, but it seems to be working with multiple sample rates!
Last edited:
All the audio gadget function patches are in mainline, 5.18. Many ARM and Intel chips provide gadget UDCs (dwc2, dwc3, etc.), the gadget functions are general for all. The gadget subsystem has a general API which all UDCs implement. E.g. Intel Atom Z8350 in touchscreen tablets from aliexpress implements dwc3 which works perfectly in the gadget mode. I tested one tablet with USB-C and one with USB-A only ports (required soldering a non-standard cable). They would make a perfect USB in -> DSP -> USB out with integrated GUI touchscreen control.
RPi provides default config files which were faulty in this version of their branch. The mainline raspberrypi config file does have this option OK, but it may not cover all rpi features. I always build the patched kernel from RPi.
RPi provides default config files which were faulty in this version of their branch. The mainline raspberrypi config file does have this option OK, but it may not cover all rpi features. I always build the patched kernel from RPi.
I thought I'd step into this thread - I'm just waiting for the Linux kernel to compile for USBAudio 2.0 support.
So far this has worked with the Mac seeing the USBAudio 1.0 g_audio in a headless RPI zero 2w install. Once the 2.0 is compiled, this should allow me to configure 192K 32bit. I have a AK5572-based ADC on it's way so that will connect to the i2c. I will initially clock this from the RPI (possibly using the timer or even the pixel clock from the HDMI port as a clock). I'll then look at clocking options for the master clock.
I'm using method #2 from this: https://gist.github.com/gbaman/50b6cca61dd1c3f88f41 and then using this for the compile: https://www.hackster.io/masonrf/rpi-zero-2-w-audio-gadget-448a6a
In short to support USBAudio2.0 basically means a kernel recompile as the changes have not got into the RPI pre-build images yet (mine was v5.15). Following the hackster guide means compiling the kernel. I would recommend (a) a larger microsd card and (b) increasing the 100MB swap file to 1024MB whilst reducing the make -j option from -j4 to -j2 so that the lower memory of RPIs can operate without the large compiles running out of memory.
A great article for adjusting the swap can be found here: https://pimylifeup.com/raspberry-pi-swap-file/
I went for a larger 128GB microsd card and used the lite build (command line only over ssh). This provides ample compile space for anything I want todo. I will install the python bode plot software to connect to the SDS1104 so I can use the RPI at a later date with a DAC too.
So far this has worked with the Mac seeing the USBAudio 1.0 g_audio in a headless RPI zero 2w install. Once the 2.0 is compiled, this should allow me to configure 192K 32bit. I have a AK5572-based ADC on it's way so that will connect to the i2c. I will initially clock this from the RPI (possibly using the timer or even the pixel clock from the HDMI port as a clock). I'll then look at clocking options for the master clock.
I'm using method #2 from this: https://gist.github.com/gbaman/50b6cca61dd1c3f88f41 and then using this for the compile: https://www.hackster.io/masonrf/rpi-zero-2-w-audio-gadget-448a6a
In short to support USBAudio2.0 basically means a kernel recompile as the changes have not got into the RPI pre-build images yet (mine was v5.15). Following the hackster guide means compiling the kernel. I would recommend (a) a larger microsd card and (b) increasing the 100MB swap file to 1024MB whilst reducing the make -j option from -j4 to -j2 so that the lower memory of RPIs can operate without the large compiles running out of memory.
A great article for adjusting the swap can be found here: https://pimylifeup.com/raspberry-pi-swap-file/
I went for a larger 128GB microsd card and used the lite build (command line only over ssh). This provides ample compile space for anything I want todo. I will install the python bode plot software to connect to the SDS1104 so I can use the RPI at a later date with a DAC too.
Last edited:
It's far faster to cross-compile on standard amd64 linux with proper SSD/NVMe and many cores/RAM when building RPi kernel https://www.raspberrypi.com/documentation/computers/linux_kernel.html#cross-compiling-the-kernel , instead of wearing off the SD card.
I have done that in the past, additionally I would probably remove the swap once the kernel is trimmed to an appropriate set of drivers. It appears even with the zero's default build, there's a more than the zero needs. It finally finished but the build time reminded me of the early 2000s!
Hello and thank you all for your hard work.
I am trying to use RPi Zero W (unfortunately cannot get my hands on the newer version...) simply as a "kind of audio mass storage" - I simply want to be able to store recorded audio samples. I was also following the guide here: https://www.hackster.io/masonrf/rpi-zero-2-w-audio-gadget-448a6a (with modifications to make it work on original Zero W). I know, I could just use it as a mass storage, however, in some environments the mass storage devices are blocked.
When testing with Linux hosts, everything works perfectly. However the max usable parameters (for my application) are 16 kHz 16 bit depth stereo. With these, the recorded file on RPi is the same as the source file. If I try to go higher, the I still get "same sounding" audio, however, when I compare the source file and the recorded file, they are completely different - probably because of quantization or something. Nevertheless this is still enough for my application.
However, when trying to use Windows 10 host, the RPi gets discovered as a device, however, the sample rate, and bit depth get are only recognized only, when they are left to their default values (64 kHz 16 bit depth).
For my application these are just too much, as the audio data just gets too distorted.
Do you know how I could try to solve the situation on Windows 10 hosts?
(the kernel version I used is 5.19.0-rc1+).
I am trying to use RPi Zero W (unfortunately cannot get my hands on the newer version...) simply as a "kind of audio mass storage" - I simply want to be able to store recorded audio samples. I was also following the guide here: https://www.hackster.io/masonrf/rpi-zero-2-w-audio-gadget-448a6a (with modifications to make it work on original Zero W). I know, I could just use it as a mass storage, however, in some environments the mass storage devices are blocked.
When testing with Linux hosts, everything works perfectly. However the max usable parameters (for my application) are 16 kHz 16 bit depth stereo. With these, the recorded file on RPi is the same as the source file. If I try to go higher, the I still get "same sounding" audio, however, when I compare the source file and the recorded file, they are completely different - probably because of quantization or something. Nevertheless this is still enough for my application.
However, when trying to use Windows 10 host, the RPi gets discovered as a device, however, the sample rate, and bit depth get are only recognized only, when they are left to their default values (64 kHz 16 bit depth).
For my application these are just too much, as the audio data just gets too distorted.
Do you know how I could try to solve the situation on Windows 10 hosts?
(the kernel version I used is 5.19.0-rc1+).
There is also some more info here for cross compiling on WSL or a Linux VM as well as uploading the compiled kernel to the rpi: https://www.hackster.io/masonrf/rpi...-newest-linux-kernel-release--cross-compile-4
I have some more info here: https://www.hackster.io/masonrf/rpi-zero-2-w-audio-gadget-448a6a#toc-testing-with-windows-hosts-6
Here are a few things to try:
- Reinstalling the device in Windows from Device Manager (see above link about halfway through that section of the guide)
- Updating Windows (some earlier Windows builds do not work well with the g_audio driver. I have really only tested on Windows 11 build 22000 or higher so I can't say much about Windows 10)
- Downgrading or upgrading the kernel version (Last I tested was an early 5.18 build which worked well)
I am not sure of your setup, but the fact that Linux only seems to work with 16kHz/16bit audio seems to indicate that using a different kernel version may fix an issue. Unless whatever device you are recording only outputs 16kHz/16bit audio in which case if you tried to record over USB at a higher sample rate and bit depth, it would have to interpolate values to fill in the extra samples which would result in the "same sounding" audio but the very different files that you have experienced. At least, that is how I interpreted your comment.
Linux and Win10 should work OK with 5.18+. What are your g_audio module params?
Thx for answers. I tried reinstalling the device in Win 10, and afterwards it worked - I can change the parameters, just have to reinstall the device, so thanks for the tip. For the "same sounding problem" I have done a bit more testing, and I have found that the problem is only present in the default windows music player - groove. With VLC the problem is gone. So I'll try to pinpoint the problem there. I did not yet try to recompile the kernel, as I did not manage to get the crosscompiling chain working, so I'll need to recompile on RPi itself, which will take some time...
The issue I seem to have with the latest build is the wifi networking seems to start, is assigned the IP address for wlan0, then is forced to shutdown. That could be a dhcp conflicting with net manager (which shouldn't be operational IIRC). Also the logs aren't being updated yet the machine runs. I've added debugging of messages in the menusetup. Annoyingly this is out of the thread and I don't want the thread to become a generic linux support.
The USB OTG g_audio works but perhaps 32bit 192K stereo is causing an issue with fitting that in the bandwidth but I don't think that should be the case. I'm not sure if OSX is playing dumb. With the standard RPI lite image I can get 96K 16bit working on the Mac which sounds USB Audio 1.0.
The USB OTG g_audio works but perhaps 32bit 192K stereo is causing an issue with fitting that in the bandwidth but I don't think that should be the case. I'm not sure if OSX is playing dumb. With the standard RPI lite image I can get 96K 16bit working on the Mac which sounds USB Audio 1.0.
On RPi4/5.18+ the USB gadget works up to maximum USB2 isochronous bandwidth of 1kbyte * 8000 microframes, tested in linux and windows wasapi exclusive (using slightly modified https://github.com/HEnquist/wasapi-rs/blob/master/examples/loopback.rs ). This is 768kHz/2ch/32bit duplex I2S DAC-> ADC 350kHz@-150dB with a dirty SMPS @54kHz (hence the peak), REW running in linux: