Subject: Re: [linux-audio-dev] realtime audio i/o with disk input
From: Paul Davis (pbd_AT_Op.Net)
Date: Wed Mar 20 2002 - 16:16:59 EET
>What I am doing:
>
>I have 3 threads:
>
>- standard priority GUI thread
>
>- audio I/O thread (SCHED_RR, max, using alsa polling)
don't ever run application threads at max priority. it makes it
impossible to construct a watchdog for runaways.
>The disk-input thread looks if it has space to write the next block
>to the circular buffer (it checks if the write-index will not cross
>the read-index). If there is no space, it waits for the readindex to
>move. This is done with a pthread_cond_wait in the disk-input thread,
>and a pthread_cond_signal in the audio i/o thread.
you don't need to use mutexes for the buffer itself. when there is one
reader and one writer, you can use a lock free ringbuffer. this will
avoid blocking the audio thread when it goes to see if there is enough
data.
however, you probably do need to use mutexes to drive the disk input
thread's operations. in ardour, the disk input thread gets woken
periodically by the audio thread when the latter believes that work
might be necessary. the disk input thread wakes up, checks on the
current state of things, and then (maybe) gets busy.
>running and it froze my machine. Hint: never write long e-mails while
>beta testing realtime priority applications ;-) )
never beta test applications with RT priority :) you don't need RT
priority to get this to work.
>- I can cause internal underruns (not filling the circular buffer in
>time), by doing a cat /dev/hda > /dev/null
>
>- Also using X-windows can cause problems. I suppose this is VM related?
are your IDE drives properly tuned with hdparm? there was a thread on
alsa-devel about in the last 24 hours in which using hdparm completely
fixed precisely this issue.
several people have reported X Window issues. this seems to be
specific to particular video adapters and/or motherboards. are you
using a low latency kernel, and is low latency turned on? which
version of XFree86 are you using, and which video adapter?
>- With what priority should the disk input thread run?
ardour's disk thread runs at default priority, SCHED_OTHER. it uses
hardly any CPU cycles (it spends most of its time asleep or waiting
for disk I/O to complete) and thus doesn't suffer from the
"interactive" penalty that ordinary programs would tend to. it will
basically run as needed.
>- Should I call mlockall? What would be the best moment to do that?
at program startup, once you know the user asked the program to run
with RT priority. mlockall() affects an entire address space, not a
thread.
>- What would be a reasonable size for the circular buffer? And what
>about the blocksize to read the data from disk? Does that even matter?
from the experiments that benno and i did last year or before, we
figured that a buffer of 5 seconds worth of data makes you immune to
just about any and all possible disk i/o and scheduling delays. that's
what ardour is using (though its user configurable).
NB: JACK contains a *tiny* program, "capture_client.c" that does all
this stuff, and records from N JACK ports to a disk file with N
channels in any format supported by libsndfile. you could study that -
its approach is a bit different from the circular buffer approach.
--p
This archive was generated by hypermail 2b28 : Wed Mar 20 2002 - 16:05:41 EET