Support for high samplerates in SW analyzers

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.
 

Attachments

  • va.png
    va.png
    107 KB · Views: 356
  • jaaa.png
    jaaa.png
    39.6 KB · Views: 351

Frex

Member
2009-11-22 7:39 pm
Hello,

Are you saying that you can send 1.536MSPS thru an Rpi USB interface see as an audio device ?
If yes, it's wonderful, you have the last missing brick i would need for my OSVA project !
I suppose you send not real audio data but digital lockup table ?

Frex
 
Last edited:
Are you saying that you can send 1.536MSPS thru an Rpi USB interface see as an audio device ?

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.

If yes, it's wonderful, you have the last missing brick i would need for my OSVA project !

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.

I suppose you send not real audio data but digital lockup table ?

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.

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: 200000
 

Attachments

  • jaaa-8M.png
    jaaa-8M.png
    43.4 KB · Views: 322
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.


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 us

Now just getting the DAC/ADC :)
 

Attachments

  • jaaa-2.6MHz.png
    jaaa-2.6MHz.png
    43.7 KB · Views: 81
"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 !
 
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.

Code:
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 1
rate: 19200000 (19200000/1)
period_size: 262144
buffer_size: 2097152

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.
 

Attachments

  • jaaa-19.2MHzFS.png
    jaaa-19.2MHzFS.png
    43 KB · Views: 58
  • zoom-19.2MHzFS.png
    zoom-19.2MHzFS.png
    40.7 KB · Views: 56
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 ?

Yes, I wanted to link that particular line of the source code and the original code has no linkable source code online :)


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.

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 ([email protected], [email protected]), 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

  • rew-1536-generating-120kHz.png
    rew-1536-generating-120kHz.png
    373.5 KB · Views: 159
  • rew-1536-sox-generator.png
    rew-1536-sox-generator.png
    316.6 KB · Views: 161

Frex

Member
2009-11-22 7:39 pm
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
 
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
 

Frex

Member
2009-11-22 7:39 pm
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
 
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 - [email protected] RPi-zero (ancient model) is sampling 2 interleaved 9bit parallel ADCs at 2x11Msps. Here you would have [email protected] 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:
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.

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: