Overruns with arecord at 192 khz 2 channel

Hi - I’m trying use pisound to record at 192khz and while it works, I get overruns after about 1 minute of recording. I’m wondering if I am missing something basic in my setup. Here’s what I see.

pi@orcasound-pi:~ $ date
Wed 6 Jun 16:21:22 UTC 2018
pi@orcasound-pi:~ $ arecord -f S32_LE -c2 -r192000 test.wav
Recording WAVE ‘test.wav’ : Signed 32 bit Little Endian, Rate 192000 Hz, Stereo
overrun!!! (at least 532.231 ms long)
overrun!!! (at least 160.454 ms long)
^CAborted by signal Interrupt…
pi@orcasound-pi:~ $ date
Wed 6 Jun 16:22:32 UTC 2018
pi@orcasound-pi:~ $

My input is a sweep from 1khz to 96khz and I can see I get a response all the way up to the 96khz as expected if I look at the spectrum (I’m using baudline). I checked my pisound-config for updates and it didn’t seem to download any.!
Here;s a screencapture of my version info
pisoundversioninfo|690x402

Any ideas of what might be going on?

Steve Hicks

I’m not sure why I didn’t seem to get the version info attached, but it’s
button 1.05
server 1.02
firmware 1.01

Stephen Hicks

Hi Steve!

First a quick overview of the problem - the ‘overrun’ means that the recording software doesn’t manage to flush all of the data into storage by the time new data is incoming, and is forced to drop parts of it. The data itself comes from a sound card independent I2S (a communication interface meant for digital audio streams) driver which itself uses the processors’ DMA (direct memory access) module to perform data copying from I2S buffers to user software with minimal supervision required by the processor. This path thus far works pretty efficiently and should not have any performance issues. The Pisound specific participation in this is just reacting to the requested stream format and configuring the ADC and DAC chips on the board, the rest is handled by the RPi I2S driver. Now we’re leaving the kernel space and entering into user space software land. There’s a lot of user space programs running concurrently, and by default every process is considered equal, so they get some share of processing time to perform their task. Time critical tasks, where data is streaming in at a constant fast rate are at risk to not have enough processing time to keep up, and this is what’s happening with the casually started arecord. Another important factor is the storage writing speed.

And here is a solution that I have just tried out and it worked great, no overruns even when performing some pretty demanding tasks on all 4 cores on my RPi 3B+. @Scott_Veirs, you may find this useful as well.

  1. First I flashed a fresh copy of Raspbian Stretch with Desktop, you may use lite too.

  2. Then I checked the write and read speeds of the SD card I’m using, as described here:

    pi@raspberrypi:~ $ sync; dd if=/dev/zero of=~/test.tmp bs=500K count=1024
    1024+0 records in
    1024+0 records out
    524288000 bytes (524 MB, 500 MiB) copied, 30.3713 s, 17.3 MB/s
    pi@raspberrypi:~ $ sync; echo 3 | sudo tee /proc/sys/vm/drop_caches
    3
    pi@raspberrypi:~ $ sync; time dd if=~/test.tmp of=/dev/null bs=500K count=1024
    1024+0 records in
    1024+0 records out
    524288000 bytes (524 MB, 500 MiB) copied, 22.9506 s, 22.8 MB/s
    
    real    0m22.962s
    user    0m0.011s
    sys     0m1.302s
    
    pi@raspberrypi:~ $ rm ~/test.tmp
    

    17.3MB/s write and 22.8MB/s read speed, pretty good, it shouldn’t cause any issues.

  3. Install JACK software, it’s the one to use for high performance audio things:

    sudo apt-get install jackd2 jack-capture
    
  4. Apply configuration for JACK to have higher priority:

    pi@raspberrypi:~ $ sudo su
    root@raspberrypi:/home/pi$ echo @audio - memlock 256000 >> /etc/security/limits.conf
    root@raspberrypi:/home/pi$ echo @audio - rtprio 75 >> /etc/security/limits.conf
    
  5. Start the jackd server as root user, to have appropriate rights to run as a higher priority process:

    root@raspberrypi:/home/pi$ JACK_NO_AUDIO_RESERVATION=1 jackd -t 2000 -P 75 -d alsa -d hw:pisound -r 192000 -p 1024 -n 10 -s
    
  6. In another terminal, start capturing what is coming in to Pisound input, also as root:

    sudo jack_capture -p system:capture*
    >>> Recording to "jack_capture_04.wav". Press <Return> or <Ctrl-C> to stop.
    >>> Less than half the buffer used. Setting higher priority for the disk thread.
    >>> Please wait while writing all data to disk. (shouldn't take long)
       |"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""|
    00:|                                                                 |
    01:|                                                                 |
    Buffer: 12.42s./12.42s  Time: 13.22m.  DHP: [x]  Overruns: 0  Xruns: 0
    Finished.
    

    During the 13 minutes, I have installed some software using apt-get and performed compilation of software on all 4 cores (make -j4), and no Xruns occurred.

  7. Finally I played back the captured audio using audacity, it sounded completely fine, I didn’t notice any glitches.

2 Likes

Thanks for the detailed info. I’m actually working with Scott:) Between the time I wrote this and now we actually went out and bought some high performance SD cards, which seemed better (like it takes 10 minutes before I get an overrun instead of 1), but let me check the performance and try Jack like you mentioned, we have been using alsa.

1 Like

@192 on a raspi you are going to get one overun every 5 to 10 minutes unless you have installed a Low Latency Kernel

1 Like