linux-kernel - Re: ALSA: Reasonable buffer size / where should it be implemented?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LNX.2.00.1102081109170.6272@eeebox2.perex-int.cz>
Date:	Tue, 8 Feb 2011 11:21:11 +0100 (CET)
From:	Jaroslav Kysela <perex@...ex.cz>
To:	Knut Petersen <Knut_Petersen@...nline.de>
cc:	tiwai@...e.de, linux-kernel@...r.kernel.org,
	alsa-devel@...a-project.org
Subject: Re: ALSA: Reasonable buffer size / where should it be implemented?

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@...ex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/