Yes, it works as "USB Device" and sends the data to PC (which is "USB Host").
"Host" and "Device" are the roles only, host initiates start initialization, enumeration, Device stnds it's descriptiors (tell to the host "who is this device and what are it's possibilities).
But the data direction is independent from the "role" - data transfer can be unidirectional (Host->Device OR Device->Host) or bidirectional (Host->Device AND Device->Host, at the same time), and also is independend from UAC1 or UAC2 operation - both supports bidirectional data transfer (if there is enough bandwidth, but this is another story).
Examples:
Any USB DAC : "Host->Device"
Any USB ADC (UMIK too): "Device->Host"
USB SoundCard: Output is Host->Device, Input is Device->Host.
Somewhat related, I recently designed a USB host-to-host bridge but that's for MIDI over USB, not for audio. Not sure it could be done for audio, at least it would be a major effort (beyond my capabilities), including resampling etc.
A possible solution could be a Raspberry Pi 4 (or CM4 + CM4 base board) for PC DSP duty as its USB can be used as device input ("gadget"), together with a DAC HAT (there's a thread on this somewhere here, IIRC). To use an USB DAC you need extra USB ports hooked up on PCI as the USB can only be either host or device (the RPi CM4 base board has a slot for PCI expansion cards). Probably a major setup and perhaps even coding effort, so no easy way.
Using SPDIF to connect two USB<-->SPDIF bridges (one sending, one receiving) might be the easiest way, as others have mentioned. You will still have the problem of syncing the DAC to that, it needs to have an SPDIF input it can sync its internal clock to (which then is used for USB clock). RME ADI2-Pro is a suitable device where you can route the SPDIF over USB to the host and use it as clock source, do some processing and send it back over USB for DAC output. Otherwise, you need resampling...
A possible solution could be a Raspberry Pi 4 (or CM4 + CM4 base board) for PC DSP duty as its USB can be used as device input ("gadget"), together with a DAC HAT (there's a thread on this somewhere here, IIRC). To use an USB DAC you need extra USB ports hooked up on PCI as the USB can only be either host or device (the RPi CM4 base board has a slot for PCI expansion cards). Probably a major setup and perhaps even coding effort, so no easy way.
Using SPDIF to connect two USB<-->SPDIF bridges (one sending, one receiving) might be the easiest way, as others have mentioned. You will still have the problem of syncing the DAC to that, it needs to have an SPDIF input it can sync its internal clock to (which then is used for USB clock). RME ADI2-Pro is a suitable device where you can route the SPDIF over USB to the host and use it as clock source, do some processing and send it back over USB for DAC output. Otherwise, you need resampling...
Correct, what is happening on the Shield is exactly what I mentioned in the second part of my post (dual role device / OTG port).
USB Gadget audio on Linux is the way to do this on an RPi as KSTR mentions.
USB hardware is either host (e.g. xHCI USB controller), or device (UDC - USB Device Controller), or capable of both operations (OTG). If the hardware does not support the device/gadget operation, no driver or userspace software can do anything about it.
Vast majority of x86 PCs have only host USB hardware. Intel mobile CPUs (Atoms, e.g. Z8350) have OTG HW, but its availability depends on initiation in BIOS. Very often it's disabled and BIOS does not offer any UI for enabling. Hacks are required to do so - e.g. https://hansdegoede.livejournal.com/25413.html . The Atom SoCs implement DWC3 Synopsys IP Core which is well supported by linux kernel. With kind help of Hans I tested the USB gadget successfully on one Atom tablet with USB-C OTG port (just device-mode enablement in BIOS config required), and on another with USB-A ports only (a hacked USB-A <-> USB-A cable was required).
NVidia Shield runs a linux kernel (android) on an ARM SoC with either DWC2 or DWC3 IP core. A software driver can switch its operation between USB host and USB device (gadget). Since the gadget driver is enabled in that specific Android linux kernel, it supports the OTG operation. It's possible only USB-A ports are installed and a cable adapter is required (which does the same as my hacked cable).
RPi ARM SoC includes DWC2 which is directly connected to the USB-C port.
That has nothing to do with audio data direction. A USB host can send (playback) as well as receive (capture, record), just like the device does. But a USB host cannot directly talk to another USB host, or a USB device to another USB device.
Vast majority of x86 PCs have only host USB hardware. Intel mobile CPUs (Atoms, e.g. Z8350) have OTG HW, but its availability depends on initiation in BIOS. Very often it's disabled and BIOS does not offer any UI for enabling. Hacks are required to do so - e.g. https://hansdegoede.livejournal.com/25413.html . The Atom SoCs implement DWC3 Synopsys IP Core which is well supported by linux kernel. With kind help of Hans I tested the USB gadget successfully on one Atom tablet with USB-C OTG port (just device-mode enablement in BIOS config required), and on another with USB-A ports only (a hacked USB-A <-> USB-A cable was required).
NVidia Shield runs a linux kernel (android) on an ARM SoC with either DWC2 or DWC3 IP core. A software driver can switch its operation between USB host and USB device (gadget). Since the gadget driver is enabled in that specific Android linux kernel, it supports the OTG operation. It's possible only USB-A ports are installed and a cable adapter is required (which does the same as my hacked cable).
RPi ARM SoC includes DWC2 which is directly connected to the USB-C port.
That has nothing to do with audio data direction. A USB host can send (playback) as well as receive (capture, record), just like the device does. But a USB host cannot directly talk to another USB host, or a USB device to another USB device.
Last edited:
