Subject: [linux-audio-dev] realtime audio i/o with disk input
From: Maarten de Boer (mdeboer_AT_iua.upf.es)
Date: Wed Mar 20 2002 - 16:17:24 EET
Hello,
I mainly write this mail to Paul Davis, but of course everybody is
welcome to answer :-)
I am trying to do realtime audio i/o in combination with disk input.
I know that Paul has a lot of experience with this. Rather than
looking through his code, I'd appreciate some description of the
approach he uses. I will comment my approach here, to see if you
consider it correct or not. .
What I am doing:
I have 3 threads:
- standard priority GUI thread
- audio I/O thread (SCHED_RR, max, using alsa polling)
- disk input thread
The disk-input thread writes to a circular buffer, reading blocks of
data from the hard-disk. It actually pre-fills it before starting the
thread.
The audio i/o thread reads from the circular buffer (and mixes it
with the soundcard input, and writes it to the soundcard output, but
that is not really relevant)
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.
pseudo-code:
disk-input thread:
pthread_mutex_lock
while writeindex+blocksize > readindex
pthread_cond_wait
pthread_mutex_lock
audio i/o thread:
pthread_mutex_lock
readindex += fragmentsize
pthread_cond_signal
pthread_mutex_unlock
In a similar way, the audio i/o thread also checks if the readindex
will not pass the writeindex, which happens when the disk input
thread did not fill the circular buffer in time. Also this is done
with a pthread_cond_signal / pthread_cond_wait.
Problems:
- It tends to run well, but sometimes it chews up a lot of CPU or
even all. I don't understand when this happens exactly. (this is the
second time I write this mail: the first time I had the application
running and it froze my machine. Hint: never write long e-mails while
beta testing realtime priority applications ;-) )
- 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?
Questions:
- Is this approach correct?
- Is the pthread_cond_wait the correct mechanism for the thread
synchronisation?
- With what priority should the disk input thread run?
- Is it better to use SCHED_RR or SCHED_FIFO for the audio i/o
thread?
- Should I call mlockall? What would be the best moment to do that?
- 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?
My system is an AMD k7 700 MHz, hdparm tuned,. 2.4.17 Andrew Morton
LL kernel.
Greatly appreciating your time and effort,
Maarten
This archive was generated by hypermail 2b28 : Wed Mar 20 2002 - 15:10:38 EET