[alsa-devel] ALSA: Reasonable buffer size / where should it be implemented?
I use a RME Digi 96 PAD audio card, and I do have buffer overrun/underrun problems if I use the standard rme96c linux driver.
I need a simple recording machine. It should not fail if e.g. cron starts updatedb or if I start a make -j 15 icecream compile job and decide to surf the internet while I record the digital satellite radio 48kHz stream.
There is a lot of information about xrun problems, but somehow that information either does not help to prevent xruns on my system, is outdated, or asks for system changes I do not accept.
No, JACK does not help. No, I do not need low latency. No, I don't want to switch to rt kernels. No, I don't want to use an audio PC without X, without cron, network, etc.
The hardware provides independent 64k ringbuffers for capture and playback, that's not more than 85msec for a 96 kHz / 2 channel / 32 bit setup or ADAT. That's simply not enough for reliable operation.
My private solution is a rme96.c that kmallocs 4 MB software buffers for capture and playback, data transfer between software and hardware buffer in the interrupt service routine. That does efficiently prevent xruns even on a really loaded system.
But I don't know if that is the right way to go.
Wouldn't it be better if there would be an (optional) software buffer one layer above the hardware driver? That would increase reliability for all audio hardware with insufficient hardware buffers.
Is there any other audio hardware with similar small buffers?
Has somebody already written an "extended alsa buffer" patch? Did I miss something?
To put it into one question: How much buffer should be provided by an alsa hardware driver module?
cu, Knut
On Tue, 8 Feb 2011, Knut Petersen wrote:
I use a RME Digi 96 PAD audio card, and I do have buffer overrun/underrun problems if I use the standard rme96c linux driver.
I need a simple recording machine. It should not fail if e.g. cron starts updatedb or if I start a make -j 15 icecream compile job and decide to surf the internet while I record the digital satellite radio 48kHz stream.
I would determine the culprit where the user space blocks. If you write data to HDD, the culprit is probably there, in my opinion. The current PC machines can handle 82ms latencies quite well.
A right behaving application should do the quick audio sample reads to a big buffer and queue these data to HDD in a separate thread to not block the audio input.
There is a lot of information about xrun problems, but somehow that information either does not help to prevent xruns on my system, is outdated, or asks for system changes I do not accept.
No, JACK does not help. No, I do not need low latency. No, I don't want to switch to rt kernels. No, I don't want to use an audio PC without X, without cron, network, etc.
The hardware provides independent 64k ringbuffers for capture and playback, that's not more than 85msec for a 96 kHz / 2 channel / 32 bit setup or ADAT. That's simply not enough for reliable operation.
My private solution is a rme96.c that kmallocs 4 MB software buffers for capture and playback, data transfer between software and hardware buffer in the interrupt service routine. That does efficiently prevent xruns even on a really loaded system.
But I don't know if that is the right way to go.
It's probably the right way to go. I would only copy data in a tasklet not directly in the interrupt routine. New hardware (like HDA) have scatter-gather DMA buffers with almost unlimited size, so users can just tune the system up.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
It's probably the right way to go. I would only copy data in a tasklet not directly in the interrupt routine. New hardware (like HDA) have scatter-gather DMA buffers with almost unlimited size, so users can just tune the system up.
Well, obviously recording to /dev/null has a better chance not to hit xrun problems ;-)
So I'll clean up my q&d rme96.c code and submit it.
I have not had a look at the sources ... is arecord "right behaving" or which command line recording tool could be used if it is not?
cu, Knut
participants (2)
-
Jaroslav Kysela -
Knut Petersen