(This thread has been quiet for a while ... hopefully it's okay to reply again, as it seems the proper place)
I've set up an RPi4 as a USB Audio Gadget (
With Windows (10) it's a different story. CamillaDSP complains about the source being stuck, and even when just using
Is there an alternative driver? Something I've not yet tried? Any pointers appreciated!
I've set up an RPi4 as a USB Audio Gadget (
g_audio driver) and it's working perfectly when Linux is used as a host.With Windows (10) it's a different story. CamillaDSP complains about the source being stuck, and even when just using
arecord, the resulting .wav file is a garbled mess. After playing with different combinations of sound format, sample rate and chunk size, I'm at a loss. It seems as though the Windows driver for these UAC devices is simply broken. I also tried setting format=1 for g_audio since I read somewhere that Windows generally does better with UAC1 than with UAC2. Still only corrupted sound on the Raspberry Pi. Despite everything matching up on both sides (S16LE and 44100Hz to keep thing simple) and always deleting the device from Windows' device manager between attempts.Is there an alternative driver? Something I've not yet tried? Any pointers appreciated!
Last edited:
More details are needed. Please give kernel version, g_audio configuration, how you play in windows, how your linux chain looks like both on host and the gadget.
Windows 10 got proper UAC2 support quite late. Which update of W10 do you have? If newest, it should be good.
Thank you both for responding so promptly. Let me try to provide the requested infos:
- Windows 10 Version is 22H2, OS build is 19045.5440
- The driver that gets installed is called "Speakers (Source/Sink)", the Device description is "Audio endpoint", the Driver date is given as 06/12/2019, which I'm not sure if that's what you meant by quite late, JukkaM?
- The Raspberry Pi kernel is 6.6.74+rpt-rpi-v8,
- the g_audio configuration is currently
options g_audio c_srate=44100 c_ssize=2 c_chmask=3 p_chmask=0 function=1 iManufacturer="Jonathan" iProduct="Merus amplifier", - Both in Linux (laptop) and Windows (gaming PC) I just played a YouTube video
- My chain on the host (laptop) is (as far as I'm aware): Firefox → Pulseaudio → Pipewire → ALSA (It's simply Manjaro Linux with
manjaro-pipewireinstalled) - My chain on the Raspberry Pi (for the purpose of testing) is:
arecord -D plughw:4,0 -f S16_LE -r 44100 /tmp/blah.wav→ ALSA → g_audio → dwc2 - The dwc2 configuration is simply
dtoverlay=dwc2,dr_mode=peripheral - When plugging the USB cable in, the last dwc2 message in dmesg is
[ 8339.261402] dwc2 fe980000.usb: dwc2_hsotg_ep_sethalt(ep 00000000d4ace487 ep1in, 0). Before that, when modprobe'ing the g_audio driver, the last g_audio message is[ 8338.888580] g_audio gadget.0: g_audio ready, and then dwc2 reports[ 8338.888630] dwc2 fe980000.usb: bound driver g_audio, which all looks good to me.
Yeah, that should be good for UAC2. Except if it introduced another problem hehe.
Ms released its UAC2 driver for W10 more than 10 years after the protocol was released.
Ms released its UAC2 driver for W10 more than 10 years after the protocol was released.
I see. That gives me a little bit of hope that perhaps I'm simply doing something wrong and it'll end up working. Perhaps the above info was already enough for phofman to be able to give a suggestion or two... fingers crossed.
IMO the version of UAC function supported by the g_audio module is selected by kernel config at build time, cannot be switched dynamically with a module parameter https://github.com/torvalds/linux/b...8/drivers/usb/gadget/legacy/audio.c#L215-L239 .
Your params look good. Did you check you are recording the stream correctly? Of course first make the gadget work with arecord or sox capture, before adding the next layer of CDSP.
Not strictly OTG related, but maybe interesting to discuss here also, because there already are some infos about CPU and Linux settings in this thread: A forist from a german forum describes how he tweaks his (Intel)CPU- and Linux-settings for audio. Maybe the one or the other of these described settings can be useful in case one runs into a real problem related to timing/resources while reproducing audio. But you also might at the same time run into the too-short-blanket paradox while tweaking: You may cosily cover you head while exposing your feet ... As for me, I basically rely on an out-of-the-box Arch minimal setup OTG which runs perfectly on a Rpi3+, without any need for tweaking. Having stated this, I also confess not being what is generally considered as an audiophile, then.
Last edited: