I’ve gone for an AK5572 based ADC. That will do 32bit with good SNR and up to stupid rates - limited by the STM32H7 which has native i2s DMA at 32bit up to 192K.
Once i have the initial bits running i will make a thread on it.
Once i have the initial bits running i will make a thread on it.
DAC chip, bit depth and sampling rate are all important. However, things like switchable input sensitivity and overvoltage protection are way more important to me when it comes to using the thing for practical work. I love my RTX for this! It's a pity only a small batch of RTX units was produced.
I've got the scarlett and it seems to work well. I run linux as well. The round trip distortion meets specs, which are pretty incredible, The inputs are a pair of combo XLR/TRS. If you want mic level, use the XLR. Line level use the TRS. A button for each channel lets you switch TRS to instrument level which adds some gain. The negatives for me have been level is just a ring that shows green/yellow/red around the gain knob. A bit course. The unit itself seems to have a fixed format interface on USB. 96KHz/32 bit. It zero pads out to 32 bits from 24. I got mine mainly for converting some old LP's to digital, and it is way overkill. Price point is right though and it works with linux. My 2c.
In the manual the scarlet sits in a restricted mode initially something like holding the 48V button for 5 seconds disables it.
Some nice work here: https://www.mvaudiolabs.com/wp-content/uploads/2021/07/MVAudioLabs-MI-1-V1.1.pdf
I may find that can run a master clock from the STM SAI but working that out needs time and for the next week or so I’m going to be maxed out.
I may find that can run a master clock from the STM SAI but working that out needs time and for the next week or so I’m going to be maxed out.
https://www.audiosciencereview.com/forum/index.php?threads/raspberry-pi-as-usb-to-i2s-adapter.8567/
The USB OTG to i2s trick seems to be nothing new. I have a rpi zero 2w sat idle that seems able todo this. No DSP is needed so the zero should easily keep up with 192k 32bit.
So mac <=usb= rpi zero <=i2s= ak adc
Still looking at the clocking (my adc board doesn’t have an onboard mclk but pcm has this).
This can be done bare metal on both the rpi and stm32, for example: https://github.com/dragonman225/stm32f469-usbaudio and as you’d expect it’s more involved plus you could make it a realtime operating system and not rpi linux so no controlled shutdown would be needed.
Options:
1. Gadgets and overlays with rpi
2. Alsaloop
3. Bare metal
It seems that this method words although windows has issues, the other point is to change sample rate requires a restart of the gadget supposedly (seems odd in my opinion).
The USB OTG to i2s trick seems to be nothing new. I have a rpi zero 2w sat idle that seems able todo this. No DSP is needed so the zero should easily keep up with 192k 32bit.
So mac <=usb= rpi zero <=i2s= ak adc
Still looking at the clocking (my adc board doesn’t have an onboard mclk but pcm has this).
This can be done bare metal on both the rpi and stm32, for example: https://github.com/dragonman225/stm32f469-usbaudio and as you’d expect it’s more involved plus you could make it a realtime operating system and not rpi linux so no controlled shutdown would be needed.
Options:
1. Gadgets and overlays with rpi
2. Alsaloop
3. Bare metal
It seems that this method words although windows has issues, the other point is to change sample rate requires a restart of the gadget supposedly (seems odd in my opinion).
Last edited:
https://www.mouser.com/datasheet/2/368/CP2114-DataSheet-1365897.pdf:
"Also supports 24-bit Play or Record (CP2114-B02 only)"
I think they got the message but you need the right chip.
"Also supports 24-bit Play or Record (CP2114-B02 only)"
I think they got the message but you need the right chip.
Obsolete and out of production it appears (both original and b02 variant).
Last edited:
Code:
$ ioreg -p IOUSB
+-o Root <class IORegistryEntry, id 0x100000100, retain 22>
+-o AppleUSBVHCIBCE Root Hub Simulation@80000000 <class AppleUSBRootHubDevice, id 0x1000004fe, registered, matched, active, busy 0 (1 ms), retain 10>
| +-o Headset@80200000 <class AppleUSBDevice, id 0x100000500, registered, matched, active, busy 0 (1 ms), retain 11>
| +-o Apple T2 Controller@80100000 <class AppleUSBDevice, id 0x100000506, registered, matched, active, busy 0 (1 ms), retain 13>
+-o AppleUSBXHCI Root Hub Simulation@14000000 <class AppleUSBRootHubDevice, id 0x10000051c, registered, matched, active, busy 0 (1 ms), retain 9>
+-o Linux USB Audio Gadget@14300000 <class AppleUSBDevice, id 0x100003910, registered, matched, active, busy 0 (1 ms), retain 15>Interesting the Mac natively only supports 96K / 32bit for USBAudio 1.0 and attempting 192K etc causes it to say it's not format not supported. Also a fair number of threads on this on the interwebs. Later I'll try a linux VM and run that. So I need to find how to set this to USBAudio 2.0..
Last edited:
Ahh found this: https://www.diyaudio.com/community/threads/linux-usb-audio-gadget-rpi4-otg.342070/page-4 so we have something already 🙂
So the current RPI kernel doesn't have USBAudio 2.0 patches pulled across yet (mine is 5.15.32-v8+ 64bit).
https://www.hackster.io/masonrf/rpi-zero-2-w-audio-gadget-448a6a
I deliberately got a 128GB microsd to take the full size of a kernel build.
So the current RPI kernel doesn't have USBAudio 2.0 patches pulled across yet (mine is 5.15.32-v8+ 64bit).
https://www.hackster.io/masonrf/rpi-zero-2-w-audio-gadget-448a6a
I deliberately got a 128GB microsd to take the full size of a kernel build.
Last edited:
I'm astonished that a current version of Alsa is not in the build. USB UAC2 has been part of ALSA for well over 10 years. Phofman here has been a significant contributor to ALSA. If UAC2 is missing they must have unearthed a very old sound driver. Did you check on how the USB enumerates the soundcard? That should give useful clues.
Send a PM to Phofman. He has been very helpful with Linux audio stuff. USB.org is a black hole for time. And a lot of the ALSA USB code is quirks to work with not quite ideal implementations. There is info in the submissions you can read that can be helpful, probably more so than USB.org descriptions of idealized implementations.
My belief is that USB.org, HDMI.org Bluetooth.sig are all ways to show how clumsy it gets to have committees of fierce competitors fight out specs. There are 5(?) versions of USBC cables that are not really interchangeable. However very few consumers are even aware of the USB2 vs. USB3 versions and why their external USBC drive is so much slower that its supposed to be. Bring this up to the committee and you get crickets. And then Thunderbolt uses the same connector. . .
My belief is that USB.org, HDMI.org Bluetooth.sig are all ways to show how clumsy it gets to have committees of fierce competitors fight out specs. There are 5(?) versions of USBC cables that are not really interchangeable. However very few consumers are even aware of the USB2 vs. USB3 versions and why their external USBC drive is so much slower that its supposed to be. Bring this up to the committee and you get crickets. And then Thunderbolt uses the same connector. . .
Here's the AK5572 ADC board:
Interesting the AK5572 doesn't have differential clock pins which would have helped reduce noise based jitter. Tomi (up in Scotland) designed and sells the boards. He has access to an AP to test designs so I'm looking forward to seeing the performance hooked up.
The kernel isn't playing nicely with the wifi and I can't access the operating machine through OTG ethernet or serial either. The kernel isn't producing logs but if configured using a different machine to edit the SD card files directly, I can make it sit as an audio device on OTG.
It could be that the device needs more power - I will try that later but for now I may end up re-flashing and then building a cross compiled kernel on the Mac mini/ubuntu VM.
Interesting the AK5572 doesn't have differential clock pins which would have helped reduce noise based jitter. Tomi (up in Scotland) designed and sells the boards. He has access to an AP to test designs so I'm looking forward to seeing the performance hooked up.
The kernel isn't playing nicely with the wifi and I can't access the operating machine through OTG ethernet or serial either. The kernel isn't producing logs but if configured using a different machine to edit the SD card files directly, I can make it sit as an audio device on OTG.
It could be that the device needs more power - I will try that later but for now I may end up re-flashing and then building a cross compiled kernel on the Mac mini/ubuntu VM.
So the second cross-compiled kernel suffers the same issue - you can see the wlan0 wifi kernel gets the IP address but then the interface is shutdown. I think there’s a conflict.
In the same, next point is creating a low jitter clock:
https://www.analog.com/en/analog-di...r-for-isolated-precision-high-speed-daqs.html
Research at the moment but the rpi will do for now. Fired the adc up on the bench power supplies for the hell of it. Not much without the rpi clocking just yet.
In the same, next point is creating a low jitter clock:
https://www.analog.com/en/analog-di...r-for-isolated-precision-high-speed-daqs.html
Research at the moment but the rpi will do for now. Fired the adc up on the bench power supplies for the hell of it. Not much without the rpi clocking just yet.