Hi,
I want digital audio input capabilities to Raspberry Pi. Is there any SPDIF/COAX to USB converters available?
Thanks and Regards,
WonderfulAudio
I want digital audio input capabilities to Raspberry Pi. Is there any SPDIF/COAX to USB converters available?
Thanks and Regards,
WonderfulAudio
There are various ways to do it. You could buy a USB recording interface that has a SPDIF input, or maybe you could buy some diy'er boards and interface them together over LVCMOS I2S bus.
WonderfulAudio, for what format do you want this converter?
Alex.
P.S. I once made one like this, but a long time ago and only for one format - 96/24.
Alex.
P.S. I once made one like this, but a long time ago and only for one format - 96/24.
you can go topping 10's right into a teensy 4.
This is another route:
https://www.ebay.com/itm/220822396127
M8805GEDS WM8805 ON DIP28 ADAPTER
This is another route:
https://www.ebay.com/itm/220822396127
M8805GEDS WM8805 ON DIP28 ADAPTER
Since RPi has I2S input, hooking an SPDIF receiver chip is quite simple, there are dedicated hats or e.g. a number of SPDIF receiver boards on aliexpress (e.g. the selection at https://www.aliexpress.com/item/1005006403414963.html or other DIR9001/WM8805 boards).
But I2S does not carry any information about the incoming rate. IMO that's the crucial feature which very few people care about, until they hit the wall when trying to capture various samplerates. Actually most USB SPDIF receivers do not handle this part properly either - since the USB host is the one selecting which samplerate to capture - how does it know what samplerate to select, when the device is the master one?
Good soundcards + drivers report this information via some side channel, e.g. alsa controls in linux. I know about a few PCI cards which do this correctly in linux alsa. It would not be complicated to do so in linux userspace with RPi, e.g. using python + I2C communication + some SPDIF receiver board with I2C control interface breakout, e.g. this board https://www.aliexpress.com/item/1005003221086905.html looks like all major WM8804 features are available on its interfaces.
But I2S does not carry any information about the incoming rate. IMO that's the crucial feature which very few people care about, until they hit the wall when trying to capture various samplerates. Actually most USB SPDIF receivers do not handle this part properly either - since the USB host is the one selecting which samplerate to capture - how does it know what samplerate to select, when the device is the master one?
Good soundcards + drivers report this information via some side channel, e.g. alsa controls in linux. I know about a few PCI cards which do this correctly in linux alsa. It would not be complicated to do so in linux userspace with RPi, e.g. using python + I2C communication + some SPDIF receiver board with I2C control interface breakout, e.g. this board https://www.aliexpress.com/item/1005003221086905.html looks like all major WM8804 features are available on its interfaces.
He asked about USB.
This is really problem.
A good way is to use a USB interface with a fixed sample rate, and ASRC between the USB interface and the SPDIF receiver.
Alex.
Yes, but also specified RPi. IMO no need to complicate with USB.
Also another way is using an SPDIF receiver with I2C control and proper alsa ASoC configuration. E.g. the ak4118 alsa driver https://www.kernel.org/doc/Documentation/devicetree/bindings/sound/ak4118.txt uses AK4118 INT0/1 outputs for to trigger updating alsa ctl element value and notifying subscribed software about the change. I could not find any ready-made AK4118 board which would break out these pins, but IMO they could be soldered to the chip legs of e.g. this board https://vi.aliexpress.com/item/1005006098129192.html . Then connecting I2S + I2C + one of these pins to RPi and using e.g. https://github.com/HEnquist/camilladsp-controller with modified reading the alsa ctl in python https://github.com/HEnquist/camilladsp-controller/blob/main/alsa_listener.py to use high-quality DSP of CamillaDSP at any incoming rate.
While the ASoC codec driver for WM8804 implements SPI/I2C communication with the transciever (and some rpi hats even use it - e.g. https://github.com/Ysurac/raspberry...t/dts/overlays/hifiberry-digi-pro-overlay.dts), the existing driver https://github.com/torvalds/linux/blob/master/sound/soc/codecs/wm8804.c does not implement any bridge between the samplerate status registers and alsa controls, like the AK4118 driver does https://github.com/torvalds/linux/b...31252c568/sound/soc/codecs/ak4118.c#L120-L126 + https://github.com/torvalds/linux/b...31252c568/sound/soc/codecs/ak4118.c#L261-L278 .
A userspace communication could be implemented though. Of course provided that particular board really connects the transciever I2C pins to some I2C interface pins of RPi pinheader which is not mentioned in aliexpress description.
A userspace communication could be implemented though. Of course provided that particular board really connects the transciever I2C pins to some I2C interface pins of RPi pinheader which is not mentioned in aliexpress description.
IMO RPi would deserve a proper SPDIF input hat, not the existing half-baked criplies. Either based on AK4114/7/8 which are already fully supported, or using the cheaper WM8804/5 which would require adding the alsa controls almost copy/paste from ak4118.c Or based on the nice PCM9211 which already has a driver https://patchwork.kernel.org/project/alsa-devel/patch/20170523090931.9697-1-julian@jusst.de/ but not part of mainline - that one already does the user-space notification at sample-rate change, nice. IMO this board could be used https://www.audiophonics.fr/en/inte...-module-spdif-i2s-analog-pcm9211-p-16720.html
Last edited:
There is no problem with controlling a SPDIF receiver connected to the RPI via I2S+I2C (or SPI) using dedicated software, but I was talking about USB as requested.
Nice chip.
I often use similar - DIX9211 (the same, but w/o ADC)
BTW, yesterday I checked on Digikey, many SPDIF receivers are obsolete now, and DIX9211 is one of the cheapest!
Alex.
I know, yet OP was mentioning RPi and IMO why complicating with USB layer when direct I2S + I2C is easier/cheaper/lower latency. I am not sure OP is aware of the I2S option, ARM is a different world from standard computers 🙂 Also it allows to avoid the ASRC which is a major simplification, IMO.
IMO there are close to zero options for proper SPDIF receiver over USB with standard UAC2 - I do not know of any standard for communicating the momentary incoming samplerate over UAC2. A custom USB feature is possible, but it requires a complicated firmware in the USB device controller and driver support on the host, unless complex USB is coded in userspace using libusb.
Just if to know the incoming sample rate and set it in RPi/PC SW, which working with UAC.
ASRC looks better.
P.S. The topic starter did not describe for what he needs this, so we can only assume various solutions.
Maybe he will always have only 44/16 (CD-DA) at SPDIF, then everything is simpler.
Alex.
Yes, we do not know. The OP has already asked about motherboard SPDIF input https://www.diyaudio.com/community/...t-to-make-a-dedicated-linux-based-dsp.426520/ and PCI-e soundcard with SPDIF input https://www.diyaudio.com/community/...nd-card-good-for-pc-digital-crossover.426745/ . In both cases he mentions a TV as SPDIF source for active DSP speakers plus cares about low latency.
I do not know if TV is fixed to single samplerate, IMO it can be at least 44.1k or 48k.
Hardware-based ASRC is definitely a safe bet. Yet all it takes is a proper SPDIF receiver with proper software support and ASRC can be avoided, ideally the SW one too 🙂 Also non-audio signals can be captured (DD, DTS, DTS-HD etc...), decoded to multichannel and DSP'd. Like a proper SPDIF input of an AV receiver.
I do not know if TV is fixed to single samplerate, IMO it can be at least 44.1k or 48k.
Hardware-based ASRC is definitely a safe bet. Yet all it takes is a proper SPDIF receiver with proper software support and ASRC can be avoided, ideally the SW one too 🙂 Also non-audio signals can be captured (DD, DTS, DTS-HD etc...), decoded to multichannel and DSP'd. Like a proper SPDIF input of an AV receiver.