Messages in this thread | | | From | Benno Senoner <> | Subject | Re: real-time threaded IO with low latency (audio) | Date | Sun, 18 Jul 1999 18:29:23 +0200 |
| |
On Thu, 17 Jun 1999, Maarten de Boer wrote: > Hi, > > I have been experimenting trying to obtain real-time I/O > with threads. The results are quite good, but not completely > satisfying. I will explain what I do, and I hope you can give > me some feedback. > > I use pthreads, one for record and one for playback. > They have a pthread_cond to wait for eachother. > I use a really small fragmentsize. (256 = 128 samples > on 22050 kHz mono)
Hmm ... use a single thread to do both (if possible), so you will have fewer sync problems.
> > When I have a playback underrun, I call > snd_pcm_flush_record and > snd_pcm_flush_playback > and do the read 2, write 1 double size thing. > > But sometimes to I/O get out of sync. I don't understand > why and what I can do. > > Is there a buffer way to bring record and playback in > sync ?
Actually Linux can't provide these low-latencies (fragment size=256), even if you don't read the PCM data from file, because sporadic disk access through daemons / update etc. , can cause a random 20-30ms stall of *ALL* processes including SCHED_FIFO ones, causing an audible sound drop out, this happens especially on IDE disks with dma=off. This is not a hardware problem but, a pure kernel problem. If you want to measure the minmum latency that you can use under various stress conditions you can use my latencytest. ( http://www.gardena.net/benno/linux/audio ).
David Olofson is developing an audio driver system for Linux which uses RT-Linux and an API which will fit well into the actual sound driver API. The goal will be a driver concept , adapting OSS/Free or ALSA to allow RTLinux tasks to access the sound drivers, and providing HARD REALTIME priority. With such a system we will able to archieve <1-2ms latency, close to the hardware limits of the soundcard, and without audio dropouts even on the highest system load ( disk I/O , gfx etc.) , because the entire Linux runs at the lowest priority. and is fully preemptable by the RT Linux tasks. It seems that RT Linux will go in to the main kernel thread with 2.4, and for reliable very low-lantency audio ( <5ms) , RTLinux seems the best way to go.
David, could you please explain in short, to the alsa and kernel folks, waht you are developing (features/pro/cons), maybe there are some people which will come up with nice ideas / suggestions ?
I think that reliable 5ms audio latency under Linux at userlevel (using SCHED_FIFO threads) will not happen very soon, since there are spinlocking problems in much parts of the kernel, plus long interrupt disablings during large disk block transfers. The KURT patches seem to make the situation better, but I've not tried them ,because the 2.1.126 kernel + KURT-patches just refuse to give out sound ( SB AWE64) on my RH6.0 box.
> > Of course I call > mlockall(MCL_CURRENT|MCL_FUTURE); > and i set the priority of the threads to SCHED_FIFO,99
> > I use alsa 0.3.0pre4. > > Any suggestions ? Is my approach correct to start with? > > Any comments will be greatly appreciated,
hmmm, your approach seems correct but unfortunately linux is not a realtime OS, and playing low-latency audio is a realtime task, linux is actually not a realtime OS, and can't even provide a "guaranteed max scheduling latency" except when you set the "max scheduling latency" to 150-4000ms , which has nothing to do with "realtime". :-)
ciao Benno.
> > Maarten
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |