SPDIF recording problems on the Cirrus Logic audio card

the ALSA command line recording tool records, but even a short ~10 second sample is bugged, and get 'overrun!!!' messages on the console frequently.

Please paste the output messages you see, so that people can see precisely the error you observe.

Where are you recording to, an SD card, or a hard disk, or some other network device? Could you try these

various file systems if you have not already?

Have you tried the command line tools with an external audio card to see if the software is broken, or the driver, or if you

have a storage related bottleneck?

You'll need to preferably try all these things, to try to narrow down the source of the problem.

Thank you shabaz for your reply.

The errors are strings like:

overrun!!! (at least 65.901 ms long)

.. it can be up to 3000 ms

The command for recording is:

arecord -c2 -f S16_LE -d 100 -r 48000 test.wav

I have tried two class 10 SD cards, and recording to an external powered USB3 HDD. All Ext4 filesystems.

I have tried with USB keyboard and mouse disconnected, with a big fan cooling the cards, and with voltage stabilizators.

I don't have any external USB soundcards, and the goal is to get this soundcard to record without dropping slices.

I have noticed that analog recording also produces overruns.

How could I debug the problem on the software level?

I don't have a Cirrus Logic card so this is guesswork, but see here: https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=43738

It is an old thread, but seems they had no issue with a partition with a different file system.

Interesting you had the same issue with a hard drive, I would not have expected that.

I do expect a big fan and voltage stabilizers to be possibly causing the issue - you do know the RPI doesn't need either,

right? They could cause an issue especially if the fan is powered from the same source. Remove them and

just power from a 2A-capable smartphone type USB power supply.

Anyway, if you have software experience and really want to debug at the software level then you could examine the source code,

insert your own hooks, etc  and recompile.

On Audacity I can record up to 10 hours error free - but sometimes it randomly crashes, and then I'm in trouble.

It was part of my troubleshooting plan to add cooling, stabilize power etc. But the cooler I added is a 220V small format cooler, so it is idependent from the PI power source. I use only 2A and 2.1A power supplys.  ...

No, this must be a software issue with arecord and the driver. I have some level of experience with linux, but I would have expected such a basic tool like arecord to work out of the box on an official image released for the soundcard.

It might be a bug with the driver, that would possibly explain why Audacity crashes - or I have some faulty hardware? ...

Could anyone, who has a sound card confirm this bug?

According to this thread: https://www.raspberrypi.org/forums/viewtopic.php?f=91&t=38387

.. using XFS for recording should help. Testing now. Had one overrun in my first test on a 10 minute sample - which is far better then it was before! (4-5 dropouts within 10 seconds)

However, I need a rock-solid, undestroyable recording device :/ .. without a single overrun in 10s of hours ....

Cooling and stabiliser is not an appropriate troubleshooting plan for this issue. Also, the fact that XFS as mentioned in the thread I referred you to has improved the situation points to it not being an arecord nor driver issue.

Using a file system on an SD card isn't going to be a good idea for latency sensitive tasks like dumping audio to disk for such sustained periods. Your requirement may be better served with a different single board computer or through more extensive experimentation with storage media such as an attached disk drive or SSD, or experimentation with smaller files i.e. rotate files so that they don't grow large.

I'd recommend using the current Raspbian (Jessie) image and manually installing an up-to-date kernel with the Cirrus drivers - this might be enough to resolve the Audacity issues. Don't use the ancient image from the element14 site, it won't do you any good.

Kernel and instructions are on my website: http://www.horus.com/~hias/cirrus-driver.html , check out this thread for more info: https://www.element14.com/community/thread/43711/l/driver-fixes-and-updates-to-kernel-31816-and-405

Also keep in mind that arecord isn't the most sophisticated recording tool out there. It's a very simple single-threaded program (no additional software buffer or separate thread to do the disk IO) and completely relies on the audio driver buffer. It alternates between reading from the audio device and writing to the file. If file IO blocks, it won't read audio data and you'll get an overrun if it blocked too long.

By default arecord/aplay try to use a buffer of 500ms. The RPi I2S driver supports up to 512k byte buffer, which is slightly below 3s at 44k1/16bit.

Try to add --buffer-time 3000000 (arecord wil automatically reduce this to the maximum available buffer size), you can also check the actual sizes/times by using the -v option. This will give you a little bit higher safety margin, maybe it's enough to get rid of the overruns.

so long,

Hias

Thank you for the tips. I'll upgrade the kernel, ...

I was able to make overrun-free 10hour takes now, with an external XFS formatted USB drive and the following command:

arecord -Dhw:sndrpiwsp -r 48000 -c 2 -f S16_LE -t raw -d 36000 | flac -f --endian=little --channels=2 --bps=16 --sample-rate=48000 --sign=signed -o /media/eee/test.flac -

The quality is good, except that I can hear a little sound of desync. It sounds like the source and the cards run independently at slightly different clock rates - both at 48khz I guess. ....

How can I make sure that the SPDIF source is my master clock?

The quality is good, except that I can hear a little sound of desync. It sounds like the source and the cards run independently at slightly different clock rates - both at 48khz I guess. ....

 

How can I make sure that the SPDIF source is my master clock?

What do you exactly mean by desync, under which circumstances does it happen?

As long as you are recording from SPDIF the Cirrus card will use that as the clock source. When you don't record from SPDIF, it'll use it's internal crystal as a clock source.

So, by having a (dummy) SPDIF recording running in the background you should also be able to playback a file to SPDIF/analog out/... and derive clocking from SPDIF input. But beware, you'll get funny results if your SPDIF source switches to a different rate while you have a playback/recording running

so long,

Hias

It appears to me that the recording via SPDIF is OK now, and the desync-like sound only appears when using the cirrus card with AES/EBU type digital in / out.