Subject: Re: [linux-audio-dev] tricks wanted for buffer cache optimization
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: su tammi 30 2000 - 15:12:12 EST
>Anyway, there is one (unsafe) trick that many applications use; fill
>only part of the memory buffers befort starting playback, and then
>let the buffers fill up in the background while playing, hoping that
>you don't hit an access latency problem while low on buffering...
Thats what I do now. There's no way to fit all the audio data in
memory, so instead, i use a thread that runs in the "background" (the
"tape butler") doing read-ahead (to a configurable distance from the
current play location) and write-behind. but as i described, the
work that this thread has to do sometimes takes way longer than the
"normal" case. the worst situation seems to be when we have to flush
and refill the buffer cache, of course.
this does work, as i said, but it requires long latency settings for
the audio interface, and careful tuning of the amount of read-ahead.
somewhat paradoxically, write-behind is not a problem in the same way
- i just use an unbounded queue of buffers to keep stuff read from the
card, and the tape butler thread get to it when it gets to it, so to
speak.
>They don't have that many tracks. Disk seek overhead is what kills
>multitrack audio...
oh, yeah. damn.
>Well, you could split the file "the other way around", but that's not
>as nice and compatible as multiple files...
what's the "other way around" ?
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:27 EST