Raspberry Pi as USB to I2S adapter

[somebodyelse]

One of the lesser known features of the Raspbery Pi Zero is that you can use its USB port in device mode with the various linux 'gadget' drivers. The audio gadget driver will make the Pi appear to be a USB audio interface when you plug it into a PC, streamer or whatever USB host, with certain limitations we'll come to in a bit. The same is probably true of the Pi 4 via the USB type C socket usually used for power, but I haven't yet seen confirmation that it works. It may also work with the Pi A and A+ but you'd need a non-standard USB cable.

The basic idea is that we use the audio gadget driver to create an audio interface via the USB port, and have another audio interface on I2S, such as the HifiBerry or Allo DAC hats. We can then configure a passthrough from one interface to the other, or put some processing like BruteFIR for room correction in between them. Initially we'll look at configuring this manually via an ssh connection, but once we've decided on what needs to be done it can be committed to config files so that you just need to plug it in and wait for it to boot.

I started with Raspbian Jessie Lite on a Pi Zero W and configured it for headless WiFi and ssh access. Follow a tutorial like this one - a search for "pi zero headless ssh wifi" and your OS should get you something suitable. If you're not familiar with ssh you should look for a tutorial on that too.

The method for enabling this functionality has changed a bit since the Zero was first released, and may change again. The method outlined in Andrew Mulholland's Gist is confirmed working with Raspbian Jessie Lite. I've not tried it with the recently released Buster version. Andrew doesn't detail the g_audio module options for setting the bit depth and sample rate though. You'd use something like:

sudo modprobe g_audio c_srate=192000 c_ssize=4 p_srate=48000 p_ssize=2

That will create a capture interface at 192kHz 32 bit (4 byte) and a playback interface at 48kHz 16 bit. I don't remember which perspective capture and playback are from though - I suspect from the Pi. This is where we meet the major limitation - currently it can only present one sample rate and format at a time for each interface. if you want to change it you have to unload the g_audio module, then load it again with the new settings:

sudo modprobe -r g_audio
sudo modprobe g_audio c_srate=96000 c_ssize=4 p_srate=96000 p_ssize=4

I'll follow up later with details of how to route audio between the interfaces.

 

[amirm]

Thanks a bunch. The limitation of one sample rate is a bummer but for my needs, I may still be able to make it work. Are all the DACs compatible with the Zero? There are no power limitations that would stop them from working since the whole thing is USB powered?

 

[somebodyelse]

So far as I know all the DACs are compatible, and enabled with the same dtoverlay setting on all Pi models. Keeping compatibility has been one of the Foundation's goals with the board revisions since the change between the original Pi and the 2. I think you'd have to set the dtoverlay accordingly when changing DACs - that's probably just commenting one line and uncommenting another in config.txt and restarting the pi.

The Zero has 2 micro-B sockets marked 'USB' and 'PWR IN' respectively. When in gadget mode it can take power from the USB one, but I don't think there's any restriction on connecting an external power adapter to the 'PWR IN' one at the same time if more power is needed. If there's going to be a problem with power I should hit it with the MiniAmp, so it's something I can check.

On the sample rate there are a couple of options, assuming we get past proof of concept with the AP. One is to add an easy to use switching method to semi-automate the rate/depth change, perhaps using buttons on GPIO pins. This will appear to the host as though the device has been unplugged then plugged in again, but with he new rate etc. The other is a set of kernel patches that let you use a comma separated list of rates in the module options, and presents all of them to the host. I've not tried these patches and don't know their current state, and don't know how they'd work with the routing between devices when the rate changes.

 

[somebodyelse]

Simple passthrough connections between audio interfaces are probably best done with alsaloop but there are other ways. For testing it may be useful to use the alsa 'tee' plugin to capture to file the data that's being sent to the output device.

On the power consumption front there's a comparison showing the Zero and some other (older) models.

I'll experiment with the Zero W, MiniAmp and Raspbian Buster Lite when I get a chance, and perhaps with a Pi 4 if I get my hands on one.

 

[amirm]

I'll experiment with the Zero W, MiniAmp and Raspbian Buster Lite when I get a chance, and perhaps with a Pi 4 if I get my hands on one.

It would be great. I have a ton of Pi hats to test and dread getting into each one! It is just so time consuming and I can't run all of my tests using the current method.

If you want to buy a Pi 4 to experiment, I am happy to pay for it. Just let me know. What would be great is if you got it working and then sent it to me so I don't have to mess with it.

 

[somebodyelse]

Pi Zero W, MiniAmp and a pair of ancient mobile phone car kit speakers are currently acting as USB speakers for my desktop with a fresh Raspbian Buster Lite. I've only tested 44.1kHz 16 bit stereo but that should be good enough to see if it'll work with the AP at all. It works both bus-powered and with a power bank plugged into the 'PWR IN' micro-b connector.

Steps to repeat
This is based on a combination of:

1. Headless Pi Zero W Wifi setup (Windows)
2. Andrew Mulholland's Gist for enabling gadget mode
3. HifiBerry's config guide
4. A couple of bits of command line stuff to load the audio gadget driver with the right parameters, and connect the audio interfaces

Start following the Headless Pi Zero W Wifi setup guide above, but using the current Raspbian Buster Lite image, 2019-07-10-raspbian-buster-lite.zip
Between Step 4 (Add Network Info) and Step 5 (Eject the Disk) we need to edit the existing 'config.txt' file to enable gadget mode, disable the onboard audio (optional) and enable the I2S DAC board:

1. Find the line '#dtparam=i2s=on' and uncomment it by deleting the '#'
2. Find the line 'dtparam=audio=on' and comment it by adding a leading '#' so it reads '#dtparam=audio=on'
3. Insert the following lines above the section starting '[pi4]':

# added to enable hifiberry miniamp and gadget audio
dtoverlay=hifiberry-dac
#dtoverlay=hifiberry-dacplus
#dtoverlay=hifiberry-digi
#dtoverlay=hifiberry-amp
dtoverlay=dwc2

NOTE: this is for the MiniAmp! For the DAC+ Pro you should comment the 'hifiberry-dac' line and uncomment the 'hifiberry-dacplus' one. We can add to this list later for other DACs.

Now proceed to Step 5 and carry on until you've finished Step 11, running from a USB power bank pr psu connected to the 'PWR IN' connector, not connected the the PC USB. Step 11 can take a while, and for me it installed a new kernel so you should really reboot it:

sudo reboot

After a minute or two you should be able to log in via ssh again. Now we can load the g_audio module, telling it what sample rate and bit depth we want to use for the capture and play back devices:

sudo modprobe g_audio c_srate=44100 c_ssize=2 p_srate=44100 p_ssize=2

The options prefixed 'c_' and 'p_' are for capture and playback interfaces respectively. srate is sample rate, and s_size is the bit depth in bytes, so 2 for 16 bit, 3 for 24 bit and 4 for 32 bit. You should now be able to list the available interfaces for recording and playback:

pi@raspberrypi:~ $ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: sndrpihifiberry [snd_rpi_hifiberry_dac], device 0: HifiBerry DAC HiFi pcm5102a-hifi-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: UAC2Gadget [UAC2_Gadget], device 0: UAC2 PCM [UAC2 PCM]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
pi@raspberrypi:~ $ arecord -l
**** List of CAPTURE Hardware Devices ****
card 1: UAC2Gadget [UAC2_Gadget], device 0: UAC2 PCM [UAC2 PCM]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

If you repeat those with the '-L' command you will get the list of all the PCM interfaces available. We'll be using the ones with the 'hw:' prefix as we want a raw interface without the possibility of resampling or format conversion:

pi@raspberrypi:~ $ aplay -L
null
    Discard all samples (playback) or generate zero samples (capture)
default:CARD=sndrpihifiberry
    snd_rpi_hifiberry_dac,
    Default Audio Device
sysdefault:CARD=sndrpihifiberry
    snd_rpi_hifiberry_dac,
    Default Audio Device
dmix:CARD=sndrpihifiberry,DEV=0
    snd_rpi_hifiberry_dac,
    Direct sample mixing device
dsnoop:CARD=sndrpihifiberry,DEV=0
    snd_rpi_hifiberry_dac,
    Direct sample snooping device
hw:CARD=sndrpihifiberry,DEV=0
    snd_rpi_hifiberry_dac,
    Direct hardware device without any conversions
plughw:CARD=sndrpihifiberry,DEV=0
    snd_rpi_hifiberry_dac,
    Hardware device with all software conversions
default:CARD=UAC2Gadget
    UAC2_Gadget, UAC2 PCM
    Default Audio Device
sysdefault:CARD=UAC2Gadget
    UAC2_Gadget, UAC2 PCM
    Default Audio Device
dmix:CARD=UAC2Gadget,DEV=0
    UAC2_Gadget, UAC2 PCM
    Direct sample mixing device
dsnoop:CARD=UAC2Gadget,DEV=0
    UAC2_Gadget, UAC2 PCM
    Direct sample snooping device
hw:CARD=UAC2Gadget,DEV=0
    UAC2_Gadget, UAC2 PCM
    Direct hardware device without any conversions
plughw:CARD=UAC2Gadget,DEV=0
    UAC2_Gadget, UAC2 PCM
    Hardware device with all software conversions
pi@raspberrypi:~ $ arecord -L
null
    Discard all samples (playback) or generate zero samples (capture)
default:CARD=UAC2Gadget
    UAC2_Gadget, UAC2 PCM
    Default Audio Device
sysdefault:CARD=UAC2Gadget
    UAC2_Gadget, UAC2 PCM
    Default Audio Device
dmix:CARD=UAC2Gadget,DEV=0
    UAC2_Gadget, UAC2 PCM
    Direct sample mixing device
dsnoop:CARD=UAC2Gadget,DEV=0
    UAC2_Gadget, UAC2 PCM
    Direct sample snooping device
hw:CARD=UAC2Gadget,DEV=0
    UAC2_Gadget, UAC2 PCM
    Direct hardware device without any conversions
plughw:CARD=UAC2Gadget,DEV=0
    UAC2_Gadget, UAC2 PCM
    Hardware device with all software conversions

Now we use 'alsaloop' to connect the USB capture interface and the I2S playback interface. Again we want to avoid any resampling or format conversion. There are probably improvements that could be made to buffering etc. as in this form it's prone to underruns if the system load increases. Note that you'll need to alter the playback device name to match the one you found with 'aplay -L' above:

alsaloop -C hw:CARD=UAC2Gadget,DEV=0 -P hw:CARD=sndrpihifiberry,DEV=0 --rate=44100 -S 0

This leaves it running at the command line and showing any error messages such as the underruns mentioned above. You can stop it and return to the comand line with 'Ctrl-c' but that will stop the audio passthrough. There are other ways to keep it going in the background, but at the moment we're jsut wanting to see that it works.

At this point you can connect to the PC USB, or anything else that'll use a UAC2 audio device, and it should work. On my linux desktop it appears as "Product: Linux USB Audio Gadget". I'd expect it to work with linux, MacOS, iOS and Android, and recent Windows 10 but probably not with older Windows versions.

When you're done use 'Ctrl-c' to stop alsaloop. A controlled shutdown is preferable, although when I tried it bus-powered before just unplugging the usb didn't break it. Anyway the nice thing to do is:

sudo halt

After a few seconds of flashing the green LED will go out, and you can disconnect.

If that works we can look at the requirements for making it easy to use for device testing.

 

[somebodyelse]

The Pi 4 arrived today. Short version: the above method works with that too.

I repeated the method above, but initially connected to a monitor and keyboard so I could see what was happening, and powered from a USB-C phone charger. After confirming it worked (booted, wifi connection ok) I shut down and connected to desktop pc, this time using a USB 3 port on the PC and an A to C cable originally supplied with a Google Pixel to connect to the Pi's USB-C connector that's usually used for power. I didn't connect the monitor or keyboard as I didn't have enough of them on the desk, but there's no reason they shouldn't work. I logged in over ssh and repeated the command line bits to load the gadget driver and make the loop connection. I then checked the audio device had appeared on the desktop, and played some music to it. Powering the MiniAmp at full volume into a pair of 4R speakers didn't seem to cause any problems, although that was with music rather than a full power test so wouldn't have been delivering the full 2x3W it's meant to be capable of.

The Pi 4 could be used with wired network rather than wireless (no need for wpa_supplicant.conf) or from screen and keyboard without a network connection, so no need for ssh or PuTTY.

 

[Jukka]

The Pi 4 arrived today. Short version: the above method works with that too.

I repeated the method above, but initially connected to a monitor and keyboard so I could see what was happening, and powered from a USB-C phone charger. After confirming it worked (booted, wifi connection ok) I shut down and connected to desktop pc, this time using a USB 3 port on the PC and an A to C cable originally supplied with a Google Pixel to connect to the Pi's USB-C connector that's usually used for power. I didn't connect the monitor or keyboard as I didn't have enough of them on the desk, but there's no reason they shouldn't work. I logged in over ssh and repeated the command line bits to load the gadget driver and make the loop connection. I then checked the audio device had appeared on the desktop, and played some music to it. Powering the MiniAmp at full volume into a pair of 4R speakers didn't seem to cause any problems, although that was with music rather than a full power test so wouldn't have been delivering the full 2x3W it's meant to be capable of.

The Pi 4 could be used with wired network rather than wireless (no need for wpa_supplicant.conf) or from screen and keyboard without a network connection, so no need for ssh or PuTTY.

Hi. I recently got RPI4, but was unable to make it work. Can you help me please? I have very little experience with Linux, but I'm a programmer, so I've got "affinity" for this kind of things. I've been thinking of building a preamp based on RPI. I don't have I2S dac, but I'm using my usb dacs for testing. My aim is to make a 4-channel (2.2 speaker system), dsp-enabled preamp with balanced dacs.

• I flashed "2019-07-10-raspbian-buster-lite.img" and "volumio-2.599-2019-08-02-pi.img" on two sd cards. Both show same results, but I've primarily tested on the Rasbian since thats what your guide is for.
• I commented out the #dtparam=audio=on in /boot/config.txt, but since I don't have I2S dac, I skipped dtoverlay=hifiberry-dac or any alternative.
• Added dtoverlay=dwc2
• I also underclocked the RPI to 1 GHz to workaround issues with weak power suplies
• Rebooted. At this point the RPI is connected to and powered by usb 3.1 port of a Win10 PC, mobo specs adequate power output.
• Run sudo modprobe g_audio c_srate=48000 c_ssize=2 p_srate=48000 p_ssize=2. Immediately I get notification in Windows of a "Linux USB Audio Gadget" with a driver error.
  • I tried different combinations of srates and ssizes since my usb dac supports up to 24/96.
• Tried alsaloop with a few different parameters, but none works.

Here be some debug:

pi@raspberrypi:~ $ aplay -L
null
    Discard all samples (playback) or generate zero samples (capture)
default:CARD=UAC2Gadget
    UAC2_Gadget, UAC2 PCM
    Default Audio Device
sysdefault:CARD=UAC2Gadget
    UAC2_Gadget, UAC2 PCM
    Default Audio Device
dmix:CARD=UAC2Gadget,DEV=0
    UAC2_Gadget, UAC2 PCM
    Direct sample mixing device
dsnoop:CARD=UAC2Gadget,DEV=0
    UAC2_Gadget, UAC2 PCM
    Direct sample snooping device
hw:CARD=UAC2Gadget,DEV=0
    UAC2_Gadget, UAC2 PCM
    Direct hardware device without any conversions
plughw:CARD=UAC2Gadget,DEV=0
    UAC2_Gadget, UAC2 PCM
    Hardware device with all software conversions
default:CARD=Audio
    NAD USB Audio, USB Audio
    Default Audio Device
sysdefault:CARD=Audio
    NAD USB Audio, USB Audio
    Default Audio Device
front:CARD=Audio,DEV=0
    NAD USB Audio, USB Audio
    Front speakers
surround21:CARD=Audio,DEV=0
    NAD USB Audio, USB Audio
    2.1 Surround output to Front and Subwoofer speakers
surround40:CARD=Audio,DEV=0
    NAD USB Audio, USB Audio
    4.0 Surround output to Front and Rear speakers
surround41:CARD=Audio,DEV=0
    NAD USB Audio, USB Audio
    4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=Audio,DEV=0
    NAD USB Audio, USB Audio
    5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=Audio,DEV=0
    NAD USB Audio, USB Audio
    5.1 Surround output to Front, Center, Rear and Subwoofer speakers
surround71:CARD=Audio,DEV=0
    NAD USB Audio, USB Audio
    7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
iec958:CARD=Audio,DEV=0
    NAD USB Audio, USB Audio
    IEC958 (S/PDIF) Digital Audio Output
dmix:CARD=Audio,DEV=0
    NAD USB Audio, USB Audio
    Direct sample mixing device
dsnoop:CARD=Audio,DEV=0
    NAD USB Audio, USB Audio
    Direct sample snooping device
hw:CARD=Audio,DEV=0
    NAD USB Audio, USB Audio
    Direct hardware device without any conversions
plughw:CARD=Audio,DEV=0
    NAD USB Audio, USB Audio
    Hardware device with all software conversions

pi@raspberrypi:~ $ arecord -L
null
    Discard all samples (playback) or generate zero samples (capture)
default:CARD=UAC2Gadget
    UAC2_Gadget, UAC2 PCM
    Default Audio Device
sysdefault:CARD=UAC2Gadget
    UAC2_Gadget, UAC2 PCM
    Default Audio Device
dmix:CARD=UAC2Gadget,DEV=0
    UAC2_Gadget, UAC2 PCM
    Direct sample mixing device
dsnoop:CARD=UAC2Gadget,DEV=0
    UAC2_Gadget, UAC2 PCM
    Direct sample snooping device
hw:CARD=UAC2Gadget,DEV=0
    UAC2_Gadget, UAC2 PCM
    Direct hardware device without any conversions
plughw:CARD=UAC2Gadget,DEV=0
    UAC2_Gadget, UAC2 PCM
    Hardware device with all software conversions

pi@raspberrypi:~ $ alsaloop -C hw:CARD=UAC2Gadget,DEV=0 -P hw:CARD=Audio,DEV=0 --rate=48000 -S 0
Sample format not available for playback hw:CARD=Audio,DEV=0: Invalid argument
Unable to set parameters for playback hw:CARD=Audio,DEV=0 stream: Invalid argument
Loopback start failure.

pi@raspberrypi:~ $ alsaloop -C hw:CARD=UAC2Gadget,DEV=0 -P default:CARD=Audio --rate=48000 -S 0
Poll FD initialization failed.

pi@raspberrypi:~ $ alsaloop -C hw:CARD=UAC2Gadget,DEV=0 -P hw:CARD=Audio,DEV=0 --rate=48000 -S 5 -A 5
Sample format not available for playback hw:CARD=Audio,DEV=0: Invalid argument
Unable to set parameters for playback hw:CARD=Audio,DEV=0 stream: Invalid argument
Loopback start failure.

I don't understand the cause of error messages and how to make it rock. Any help thanks

PS. I hate to break a first post like this, but thanks @amirm for this great site! I spend most of my lunch breaks reading through articles here!

 

[somebodyelse]

Immediately I get notification in Windows of a "Linux USB Audio Gadget" with a driver error.

What's the driver error? I don't have Win10 to test with, and this may be a showstopper.

pi@raspberrypi:~ $ alsaloop -C hw:CARD=UAC2Gadget,DEV=0 -P hw:CARD=Audio,DEV=0 --rate=48000 -S 0 Sample format not available for playback hw:CARD=Audio,DEV=0: Invalid argument Unable to set parameters for playback hw:CARD=Audio,DEV=0 stream: Invalid argument Loopback start failure.

The interfaces starting hw: are raw hardware interfaces and only work with sample rates, bit depths and channel counts supported by the hardware. Interfaces starting plughw: will (try to) convert to a format that is supported by the hardware. To just get something to play you can skip the options that were there to force it not to mess with the data, so this should be more likely to work:

pi@raspberrypi:~ $ alsaloop -C hw:CARD=UAC2Gadget,DEV=0 -P plughw:CARD=Audio,DEV=0

In the longer term I guess you won't be using alsaloop at all, just BruteFIR taking input from the usb gadget, doing your crossover and perhaps room correction, and passing data out to your multichannel USB DAC.

I also underclocked the RPI to 1 GHz to workaround issues with weak power supplies

You could supply 5V via the header pins so it's not relying on the PC's USB port for power. A lot of the amp hats and some of the dac hats (audiophonics, maybe others) do this.

 

[somebodyelse]

I can reproduce the 'sample format not available for playback' error with my Focusrite Fortewhich accepts only S32_LE and has 4 output channels. Changing to plughw: for that and removing the other options as I suggested above removes that error, but quickly fails with a 'Bus error'. dmesg is showing an allignment exception, so I think we've found a bug.

As a workaround you can use record from the gadget using arecord and pipe the stream to aplay to send it to the output. Since it's using a raw format you need to specify the sample rate, bit depth and channel count. If you're using a hw: interface the raw format needs to be one that's supported by the interface. In this case I'm specifying the raw format that matches the gadget interface module settings, and using plughw: on the output to convert to a format that the Forte can handle. I'll show the modprobe so you can see the matched settings:

sudo modprobe g_audio c_srate=44100 c_ssize=2 p_srate=44100 p_ssize=2
arecord -D hw:CARD=UAC2Gadget,DEV=0 -t raw -f S16_LE -c2 -r44100 | aplay -D plughw:CARD=Forte,DEV=0 -t raw -f S16_LE -c2 -r44100

You'll need to terminate with Ctrl-c when you're finished testing.

You can use alsa-capabilities to see what your devices are capable of. It's not packaged separately for debian/raspbian, but it's included in the brutefir extension for volumio.

 

[Jukka]

First, thanks for quick and informative reply!

Second, I tried your suggested "plughw" version on alsaloop and that didn't produce an error, so my guess is thats the way to go for testing.

Third, the Win10 error. RPI doesn't give any errors. My Win10 locale seems to be finnish, but I'll check later if I can change it to english for more shareable error messages. Looking at my Device Manager --> Audio, video etc --> there is a "Source/Sink", thats got a yellow exclamation mark. Looking at properties: Device state: "Device cannot start. (Code 10)", Google thinks it's a driver issue. Looking at events: I can see that the Windows applied its usbaudio2.inf on it, but it wont work. Thats a brand new driver from Ms if I'm not mistaken. 3 events, not sure how much info is relevant at this point:

• Device USB\VID_1D6B&PID_0101&MI_00\7&3509f524&0&0000 requires further installation.
• Ohjaimien hallinta on viimeistellyt palvelun usbaudio2 lisäysprosessin (laite-esiintymätunnus USB\VID_1D6B&PID_0101&MI_00\7&3509F524&0&0000). Tila: 0.
• Ohjaimien hallinta viimeisteli ohjaimen usbaudio2.inf_amd64_3e0646bbacd51a3d asennusprosessin (laite-esiintymätunnus USB\VID_1D6B&PID_0101&MI_00\7&3509F524&0&0000). Tila: 0x0.

Something this specific is difficult to Google, but I'll spend some time on it...

Fourth, if I can make this proof-of-concept work, I'll go get some more peripherals and finesse.

 

[somebodyelse]

First, thanks for quick and informative reply!

Thanks for testing. It's useful finding out what does and doesn't work with other OSs and hardware.

Third, the Win10 error. RPI doesn't give any errors. My Win10 locale seems to be finnish...

I'll leave that to those who know more about Windows. One look at the driver quirks handling in the alsa drivers will show how many subtle differences in interpretation of UAC2 there are, so it's not entirely unexpected.

 

[Jukka]

Thanks for testing. It's useful finding out what does and doesn't work with other OSs and hardware.

I'll leave that to those who know more about Windows. One look at the driver quirks handling in the alsa drivers will show how many subtle differences in interpretation of UAC2 there are, so it's not entirely unexpected.

I have found a recent diyaudio thread of somebody else (pun intended) doing the exact same thing as I. And after trying has concluded to use other approach than g_audio for connecting, since that simply won't work with Windows at the current state of involved drivers.

I will post in threads when I make progress.

 

[Krunok]

Hi. I recently got RPI4, but was unable to make it work. Can you help me please? I have very little experience with Linux, but I'm a programmer, so I've got "affinity" for this kind of things. I've been thinking of building a preamp based on RPI. I don't have I2S dac, but I'm using my usb dacs for testing. My aim is to make a 4-channel (2.2 speaker system), dsp-enabled preamp with balanced dacs.

I'm using BruteFIR plugin for Volumio for the same purpose. It works best with Volumio 2.555 version. Currently plugin it supports only 2 channels but I'm trying to convince the developer to extend it's functionality to 4 channels so I can integrate a SW into my system.

 

[somebodyelse]

Thanks - a useful thread. In summary the linux g_audio driver works fine with MacOS and linux, but not with the Windows 10 UAC2 driver. It's been reported both to Microsoft and to the linux kernel mailing list, although there's no sign on either that any changes are happening. Meanwhile at diyaudio after some discussion in the thread mentioned above, the work on implementing the thing that Windows demands but g_audio doesn't implement has moved to this diyaudio thread.

 

[Jukka]

I'm using BruteFIR plugin for Volumio for the same purpose. It works best with Volumio 2.555 version. Currently plugin it supports only 2 channels but I'm trying to convince the developer to extend it's functionality to 4 channels so I can integrate a SW into my system.

That would be great! The offerings are surprisingly limited for dsp 4 channel balanced output. The closest real competition is the miniDSP SHD, which is quite pricey in diy terms. Just finding 4 channels of balanced output dac is difficult. My top choice currently is a pair of E1DAs with appropriate adapters to full xlr-connectors. Depends though, the upcoming KTB is quite interesting.

But all these dacs being stereo-only, is it possible to use two I2S dacs with RPi?

 

[Krunok]

That would be great! The offerings are surprisingly limited for dsp 4 channel balanced output. The closest real competition is the miniDSP SHD, which is quite pricey in diy terms. Just finding 4 channels of balanced output dac is difficult. My top choice currently is a pair of E1DAs with appropriate adapters to full xlr-connectors. Depends though, the upcoming KTB is quite interesting.

But all these dacs being stereo-only, is it possible to use two I2S dacs with RPi?

It's not. But even if it would be you would encounter a problem of timing as each DAC will have it's own clock which will differ from one another.

I was thinking about miniDSP U-DAC8 but if you need multichannel DAC with balanced outputs I recommend MOTU UltraLite-mk4.

 

[Jukka]

I was thinking about miniDSP U-DAC8 but if you need multichannel DAC with balanced outputs I recommend MOTU UltraLite-mk4.

Thanks for the tip. I will first try with two usb dacs that I have in hand and when I know that I can make it work as intended, I will invest more money. In theory one can combine two SE outputs into one balanced, but it doesn't sound reasonable if real balanced dacs are available.

 

[Krunok]

Thanks for the tip. I will first try with two usb dacs that I have in hand and when I know that I can make it work as intended, I will invest more money. In theory one can combine two SE outputs into one balanced, but it doesn't sound reasonable if real balanced dacs are available.

Using 2 DACs without getting them in sync with master clock won't work well.

 

[Jukka]

Using 2 DACs without getting them in sync with master clock won't work well.

I suspected as much. Though I was hoping that two identical usb dacs would run in sync if the source is one RPi. I got the idea from miniDSP SHD, since it has two spdif output ports for 4 channels, but I guess they paid attention in keeping them in sync. Any facts available on how this would look like with RPi and it's usb? I also guess based on a quick-Google that multichannel GPIO I2S is not easy/possible. Maybe we need to persuade Ivan to make a 4 channel version..