After a few patches the RPI4 USB audio class 2 gadget supports the maximum 1024bytes packets size in USB2 microframe (i.e. 8000 x 1024 bytes = 65Mbits/s duplex throughput) now. Good opportunity to test how common software analyzers deal with high samplerates.
Tested in linux which accepts any samplerate reported by the USB audio device. I configured the gadget to use 1536kHz/24bit/1ch (36.9Mbits/s), with sox generating 700kHz sine signal on the RPi. The USB host was capturing from the USB gadget and analyzing .
Arta in wine - fixed samplerate at 192kHz, not working
REW - not tested yet but definitely will require low-latency garbage collector of the latest java.
Audacity - while it accepts files with any samplerate (I have tested 10MHz files), its soundcard backend is limited by portaudio samplerate range, probably could be changed and recompiled. Stock version not working.
VisualAnalyzer in wine - did not offer the device samplerate, but could be configured at any samplerate. Would require some work (from its author as it is not open source) but its potential is quite good. Screenshot taken.
jaaa - a simple open source FFT analyzer in linux, works OK. Unfortunately only 128k FFT length which is quite little. But this could be changed in the source code. Screenshot taken.
Tested in linux which accepts any samplerate reported by the USB audio device. I configured the gadget to use 1536kHz/24bit/1ch (36.9Mbits/s), with sox generating 700kHz sine signal on the RPi. The USB host was capturing from the USB gadget and analyzing .
Arta in wine - fixed samplerate at 192kHz, not working
REW - not tested yet but definitely will require low-latency garbage collector of the latest java.
Audacity - while it accepts files with any samplerate (I have tested 10MHz files), its soundcard backend is limited by portaudio samplerate range, probably could be changed and recompiled. Stock version not working.
VisualAnalyzer in wine - did not offer the device samplerate, but could be configured at any samplerate. Would require some work (from its author as it is not open source) but its potential is quite good. Screenshot taken.
jaaa - a simple open source FFT analyzer in linux, works OK. Unfortunately only 128k FFT length which is quite little. But this could be changed in the source code. Screenshot taken.
Attachments
The max. current bandwidth is 1024 bytes per 8000 microframes per second, i.e. 65,536,000 bits per second. You can split it by samplerate, sample bitwidth and channel count as you wish. For 24bit/1ch that makes 2,730,666 samples per second.
The gadget is still adaptive, i.e. timed by the USB host. That is OK e.g. for a DSP loopback mode with no extra clock involved. But you have a master clock by your ADC, you need an async chain controlled by your clock. Still quite some work to achieve that. But that is my plan.
The more difficult question is how to get samples from your ADC to the RPi, to be sent to USB host in the USB audio format.
Sox generates a regular 24bit audio stream. Of course the stream is artificially generated on RPi, I have no 2.3MHz 24bit capturing device hooked to the RPi.
Last edited:
jaaa is really trivial to modify, nice code.
Max FFT length increased to 8M, min. amplitude lowered to -220dB. The analyzer takes about 30% of one core. Fundamental determined exactly at 1100000.0Hz. Completely stable operation on both sides, no buffer xruns.
Max FFT length increased to 8M, min. amplitude lowered to -220dB. The analyzer takes about 30% of one core. Fundamental determined exactly at 1100000.0Hz. Completely stable operation on both sides, no buffer xruns.
Code:
sox -V -r 2304000 -n -b 24 -c 1 -t alsa hw:2 synth 100000 sine 1100k
sox: SoX v14.4.2
Input File : '' (null)
Channels : 1
Sample Rate : 2.304e+06
Precision : 32-bit
Output File : 'hw:2' (alsa)
Channels : 1
Sample Rate : 2.304e+06
Precision : 24-bit
Sample Encoding: 24-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no
sox INFO sox: effects chain: input 2.304e+06Hz 1 channels
sox INFO sox: effects chain: synth 2.304e+06Hz 1 channels
sox INFO sox: effects chain: output 2.304e+06Hz 1 channels
Code:
Capture:
Status: Running
Interface = 2
Altset = 1
Packet Size = 864
Momentary freq = 2304000 Hz (0x120.0000)
Interface 2
Altset 1
Format: S24_3LE
Channels: 1
Endpoint: 1 IN (ASYNC)
Rates: 2304000
Data packet interval: 125 us
Code:
access: MMAP_INTERLEAVED
format: S24_3LE
subformat: STD
channels: 1
rate: 2304000 (2304000/1)
period_size: 100000
buffer_size: 200000Attachments
Finally the usable maximum available - 14 x 192kHz = 2.688MHz. Spectrum for sine at 1.3MHz 0dBFS. Packet size 1008 is getting close to maximum 1024.
Now just getting the DAC/ADC
Code:
Capture:
Status: Running
Interface = 2
Altset = 1
Packet Size = 1008
Momentary freq = 2688000 Hz (0x150.0000)
Interface 2
Altset 1
Format: S24_3LE
Channels: 1
Endpoint: 1 IN (ASYNC)
Rates: 2688000
Data packet interval: 125 usNow just getting the DAC/ADC
Attachments
"jaaa is really trivial to modify, nice code." I have experience with building RPM packages (and working with Linux professionally since 25 years) but I´m not a C programmer. Can you give me some advice how you modified the code to achieve this (ideally a patch file) ? I have used jaaa in the past and would really like to try this. Many thanks in advance !
The FFT_MAX constant is jaaa/spectwin.h at master * gesellkammer/jaaa * GitHub
I also changed the minimum amplitude to -240 jaaa/spectwin.cc at master * gesellkammer/jaaa * GitHub for viewing digitally-precise signals.
I just changed those two numbers in packages sources and recompiled/reinstalled the jaaa package.
What audio source are you planning to use? Unfortunately snd-aloop has upper limit at 192kHz. I am compiling kernel to try lifting that limit.
I also changed the minimum amplitude to -240 jaaa/spectwin.cc at master * gesellkammer/jaaa * GitHub for viewing digitally-precise signals.
I just changed those two numbers in packages sources and recompiled/reinstalled the jaaa package.
What audio source are you planning to use? Unfortunately snd-aloop has upper limit at 192kHz. I am compiling kernel to try lifting that limit.
Recompiled kernel, raising the max. samplerate of the loopback device snd-aloop to 19.2MHz by changing one parameter. Also max buffer size raised to 2MB for timing safety.
At samplerate 19.2MHz single-threaded sox does not keep up with generating sine signal, I had to pre-generate 32bit wav at 19.2MHz samplerate, 9.2MHz sine tone -3dB. 1 minute of signal takes 4GB on drive, bitrate 614Mbps. The test really requires SSD drives.
I used aplay for playback for good control of buffer/period sizes. aplay plays perfectly at that rate, absolutely stable. Using whole the available 2MB of buffer, period size 256kB. This means the player feeds data to the playback device every 262144/(19200000*4) = 3ms.Yet aplay takes 3% of an old xeon core.
Jaaa capturing from the loopback device holds the flag. At 130% CPU it manages to analyze 8M FFT (bin width 2.29Hz) with no hiccups, UI operable with slight sub-second delayed reactions.
The first screenshot is complete spectrum.
The second screenshot shows maximum frequency zoom with span 9.6kHz and center frequency 9.2MHz. The two markers are 9Hz apart, I could not place them closer with my mouse.
Current PC hardware (my workstation is 8yrs old) offers huge performance if the software is written properly.
At samplerate 19.2MHz single-threaded sox does not keep up with generating sine signal, I had to pre-generate 32bit wav at 19.2MHz samplerate, 9.2MHz sine tone -3dB. 1 minute of signal takes 4GB on drive, bitrate 614Mbps. The test really requires SSD drives.
I used aplay for playback for good control of buffer/period sizes. aplay plays perfectly at that rate, absolutely stable. Using whole the available 2MB of buffer, period size 256kB. This means the player feeds data to the playback device every 262144/(19200000*4) = 3ms.Yet aplay takes 3% of an old xeon core.
Code:
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 1
rate: 19200000 (19200000/1)
period_size: 262144
buffer_size: 2097152Jaaa capturing from the loopback device holds the flag. At 130% CPU it manages to analyze 8M FFT (bin width 2.29Hz) with no hiccups, UI operable with slight sub-second delayed reactions.
The first screenshot is complete spectrum.
The second screenshot shows maximum frequency zoom with span 9.6kHz and center frequency 9.2MHz. The two markers are 9Hz apart, I could not place them closer with my mouse.
Current PC hardware (my workstation is 8yrs old) offers huge performance if the software is written properly.
Attachments
Last edited:
The GitHUb repository is a fork of the original source at Kokkini Zita - Linux Audio is there any special reason why you used that fork ? FFT_MAX and the minimum aplitude are the two things I´m interested to, for the sample rate limit of 192kHz it is so that I dont own any hardware that supports more.
Yes, I wanted to link that particular line of the source code and the original code has no linkable source code online
Neither do I, that is why I used the USB-audio RPi gadget first and than the the virtual sound device snd-aloop with increased samplerate limit. You can use that as well should you need it.
REW shows that multiplatform java can provide great performance, if the project is designed and implemented correctly. John Mulcahy has kindly built a trial version with increased limits of samplerate to 1,536kHz, FFT to 4M, buffers to 512k. HW-accellerated graphics in OpenGL drops the display process load to virtually zero. That allowed testing REW efficiency and performance in my modified linux alsa loopback.
1,536kHz samplerate, signal generated by REW generator with two extra distortions enabled (H2@-130dB, H3@-140dB), FFT 4M, display resolution 2560x1440. Generated frequency set to one decimal place 121,533.3Hz (the input field displays just the integer part), FFT measured it precisely. The added distortions measured correctly. All of that operating completely stable (notice the 155 averages) with load of 90% of single CPU core.
The second screenshot confirms the precision of REW 4M FFT with an external signal generator - SoX generating 720,511.8Hz (close to the Nyquist's 768kHz) - again REW measures the fundamental precisely. CPU load of 60% for the java of the analyzer is an excellent figure. Please notice how efficient REW is - 60% REW + 30% C-coded sox = 90%, the same load when REW generated the sine signal itself + it was adding the two requested distortions.
John only raised the limits and increased buffers of his standard REW release, I did not do any tweaks to the linux audio subsystem, no elevated priorities or real-time processes. REW was running on stock open-source OpenJDK1.8 included in Ubuntu 18.04.
IMO REW has a great potential for near-future high-samplerate devices. And the only truly multiplatform project I know about.
1,536kHz samplerate, signal generated by REW generator with two extra distortions enabled (H2@-130dB, H3@-140dB), FFT 4M, display resolution 2560x1440. Generated frequency set to one decimal place 121,533.3Hz (the input field displays just the integer part), FFT measured it precisely. The added distortions measured correctly. All of that operating completely stable (notice the 155 averages) with load of 90% of single CPU core.
The second screenshot confirms the precision of REW 4M FFT with an external signal generator - SoX generating 720,511.8Hz (close to the Nyquist's 768kHz) - again REW measures the fundamental precisely. CPU load of 60% for the java of the analyzer is an excellent figure. Please notice how efficient REW is - 60% REW + 30% C-coded sox = 90%, the same load when REW generated the sine signal itself + it was adding the two requested distortions.
John only raised the limits and increased buffers of his standard REW release, I did not do any tweaks to the linux audio subsystem, no elevated priorities or real-time processes. REW was running on stock open-source OpenJDK1.8 included in Ubuntu 18.04.
IMO REW has a great potential for near-future high-samplerate devices. And the only truly multiplatform project I know about.
Attachments
phofman, well done for interacting with John Mulcahy at the bleeding edge of capabilities. John has always been supportive and open to enhancing his platform in a very realtime manner over many years, which for a software product is almost unheard of, and his package just keeps advancing in what seems to be very user-led and suggested aspects.
Hello,
Thats great ! I love RAW too.
I never tried to use it on linux, but i would like that ! (Jaaa is good but very limited).
So now, we have to found the USB hardware interface who could handle the 1536kHz stream rate ...
On my OSVA project, i will be possible to use the mini-DSP USB-streamer or it's newer MCH-streamer brother.
The last one allow 4 channels @ 384kHz in and out.
So, it is possible to slice the 1536kHz stream in 4 I2S @ 384k to send the full sample rate.
So, of course RAW would need to merge them in one to get the total rate.
DO you think that possible? (I know that HpW member have already done this on his FFT software HpW-works).
Frex
Thats great ! I love RAW too.
I never tried to use it on linux, but i would like that ! (Jaaa is good but very limited).
So now, we have to found the USB hardware interface who could handle the 1536kHz stream rate ...
On my OSVA project, i will be possible to use the mini-DSP USB-streamer or it's newer MCH-streamer brother.
The last one allow 4 channels @ 384kHz in and out.
So, it is possible to slice the 1536kHz stream in 4 I2S @ 384k to send the full sample rate.
So, of course RAW would need to merge them in one to get the total rate.
DO you think that possible? (I know that HpW member have already done this on his FFT software HpW-works).
Frex
Frex:
I wonder if the MCH-streamer can really do 386k/24b/8ch as it exceeds data capacity of single isochronous transaction per USB high-speed microframe (1024 bytes * 8000 frames/s = 8,192,000 bytes per second while that stream is 9,216,000 bytes/s). Maybe they have implemented the multiple transactions per microframe, but I am not sure standard UAC2 host-side drivers support it out of the box.
Merging four streams to one faster stream which audio applications can use is certainly no problem in linux, e.g. something like this in sox effect: upsample 4 delay 0s 1s 2s 3s remix 1v1,2v1,3v1,4v1
I wonder if the MCH-streamer can really do 386k/24b/8ch as it exceeds data capacity of single isochronous transaction per USB high-speed microframe (1024 bytes * 8000 frames/s = 8,192,000 bytes per second while that stream is 9,216,000 bytes/s). Maybe they have implemented the multiple transactions per microframe, but I am not sure standard UAC2 host-side drivers support it out of the box.
Merging four streams to one faster stream which audio applications can use is certainly no problem in linux, e.g. something like this in sox effect: upsample 4 delay 0s 1s 2s 3s remix 1v1,2v1,3v1,4v1
Hello phofman,
I don't know if it really can, but it is advertised as ! (Datasheet HERE)
I have the USB-streamer that can handle 4x192k in + 4x192k out,
and i will test this as soon it will be possible.
Anyway, If the MCHStreamer can "only" manage 4x 384kHz IN (so no OUT used in this mode), that could satisfy me too.
Regards.
Frex
I don't know if it really can, but it is advertised as ! (Datasheet HERE)
I have the USB-streamer that can handle 4x192k in + 4x192k out,
and i will test this as soon it will be possible.
Anyway, If the MCHStreamer can "only" manage 4x 384kHz IN (so no OUT used in this mode), that could satisfy me too.
Regards.
Frex
IIUC you are already doing some high-speed processing from single 100MHz SPI of LTC2380-24 to multiple I2S interfaces you want to connect to the USB-streamer. The MCHStreamer costs over 100USD.
I believe a fast inexpensive MCU (e.g. STM32H750VB board STM32H7 Development Board STM32H750VBT6 STM32H743VIT6 Core Board Minimum System Board|Contactors|Home Improvement - AliExpress for 18USD running at 480MHz with SPI max 133MHz) would have no problem reading the ADC SPI signal and outputting parallel 24bit to GPIOs. RPi4 for 35USD would read the 24bit 1.5MHz parallel signal and output directly USB-audio class 2 signal to any USB host �� Reaching 80MHz . The USB-audio gadget code will soon receive async feedback support Re: usb:gadget:f_uac2: EP OUT is adaptive instead of async - Ruslan Bilovol , making it perfectly suitable for these purposes.
Look at this open-source project 1.5 RPi ultrasound imaging platform * Hacking ultrasound with a DIY dev kit - single-core@1GHz RPi-zero (ancient model) is sampling 2 interleaved 9bit parallel ADCs at 2x11Msps. Here you would have 4-core@1.6GHz RPi4 sampling 24bits at 1.5Msps...
Edit - he is actually sampling 18bits at 10Msps
Edit2 - inspired by Raspberry Pi as an Oscilloscope @ 10 MSPS | digibirds side
I believe a fast inexpensive MCU (e.g. STM32H750VB board STM32H7 Development Board STM32H750VBT6 STM32H743VIT6 Core Board Minimum System Board|Contactors|Home Improvement - AliExpress for 18USD running at 480MHz with SPI max 133MHz) would have no problem reading the ADC SPI signal and outputting parallel 24bit to GPIOs. RPi4 for 35USD would read the 24bit 1.5MHz parallel signal and output directly USB-audio class 2 signal to any USB host �� Reaching 80MHz . The USB-audio gadget code will soon receive async feedback support Re: usb:gadget:f_uac2: EP OUT is adaptive instead of async - Ruslan Bilovol , making it perfectly suitable for these purposes.
Look at this open-source project 1.5 RPi ultrasound imaging platform * Hacking ultrasound with a DIY dev kit - single-core@1GHz RPi-zero (ancient model) is sampling 2 interleaved 9bit parallel ADCs at 2x11Msps. Here you would have 4-core@1.6GHz RPi4 sampling 24bits at 1.5Msps...
Edit - he is actually sampling 18bits at 10Msps
Edit2 - inspired by Raspberry Pi as an Oscilloscope @ 10 MSPS | digibirds side
Last edited:
Linux does support the high-bandwidth mode directly in the core USB driver linux/urb.c at master * torvalds/linux * GitHub , that means max. isochronous transfer rate for USB audio class 2 is 1024bytes * 3 packets * 8000 uframes per second = 196Mbps, i.e. e.g. 4,096kHz/24bit/2ch each direction duplex. Enough of margin for the forseeable future
Last edited:
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.