Overruns with arecord at 192 khz 2 channel

Pisound Support
3

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