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/