Subject: Re: [ecasound] weird delay in real time processing
From: S. Massy (email@example.com)
Date: Sun Jun 11 2000 - 19:12:13 EEST
Most of the problems I reported (related to recording to a file while
doing realtime stuff) are gone away by now. To anyone doing realtime
processing on linux I highly recomment the following:
- The Audio Quality HOWTO: http://www.linuxdj.com/audio/quality
- The Low-latency Mini HOWTO: http://www.crosswinds.net/~linuxmusic/lowlatency.html
- The Linux UDMA Mini-HOWTO: http://www.moisty.org/linux/Ultra-DMA.html
Now, this said and cleared away I remain with the following problems:
- Whenever I'm doing some realtime playback/recording with something
# ecasound -i:/dev/dsp -o:/dev/dsp -r
I still get the variable lag (from none to about one second) between
ins and outs. The only clue I might have found so far is that the
problem seems less important when not using double buffering.
- When using the alsa devices with something like:
# ecasound -i:alsa,0,0 -oalsa,0,0 -r
Everything is perfect for maybe twenty seconds then the sound goes
very bad. The best way I can describe it is what happens when you set
a delay unit with very short delay time (between 1 and 10 MS) with an
high feedback level.
Well, I'd be happy if anyone could suggest something as what might be
the cause of either of these problems.
On a side note here's an excerpt from the Low-latency howto:
"If you plan to stream audio from/to disk, use a 2 threaded model:
the player thread running at max priority, and the disk thread running
at lower priority and exchange data by using shared memory or pipes."
Am I wrong to think that when running with -m:mthreaded and -r options
all threads are actually SCHED_FIFO? If so, would the idea of
implementing the suggestion above be worthwhile, something like a -rt
-- To unsubscribe send message 'unsubscribe' in the body of the message to <firstname.lastname@example.org>.
This archive was generated by hypermail 2b28 : Tue Jun 20 2000 - 07:46:21 EEST