Re: [linux-audio-dev] tricks wanted for buffer cache optimization

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] tricks wanted for buffer cache optimization
From: David Olofson (audiality_AT_swipnet.se)
Date: su tammi  30 2000 - 14:51:25 EST


On Sun, 30 Jan 2000, Paul Barton-Davis wrote:
> The Gigasampler approach isn't enough here: we allow random access to
> various parts of many (20+) enormous (up to 100minutes of
> 32bit/96kHz!) audio files, not sequential access to a few (what, 4-10
> max?) small samples ... reading in the first 5secs doesn't solve much
> for an HDR system.

True, the GigaSampler "trick" relies on tha fact that there is a
limited number of playback start points... A very different concept,
in this regard.

> If necessary, I can start using the old watch cursor, and make people
> wait while the tape butler does its work, but it would be really
> *nice* to get true, "instant" (i.e. faster than typical human physical
> response) tape positioning regardless of the number of tracks or file size.

I can't see any way of doing that, at least not with standard
drives, normal file systems and non-interleaved files. It would
require bounded seek time and keeping track of exactly where data is
stored physically on the disk, for real time disk access scheduling.

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...

> OK, OK, this is all old stuff because video guys have to deal with it,
> and so do some other apps, I would think.

They don't have that many tracks. Disk seek overhead is what kills
multitrack audio...

> ps. i'm starting to wonder if a non-interleaved h/w is really the
> right design. we would do much better with disk access if
> the data was interleaved in both directions. OTOH, the infamous
> 4GB file size would soon kick in with multi-track files, so
> there are other reasons why this a problem in the near term.

Well, you could split the file "the other way around", but that's not
as nice and compatible as multiple files...

//David

.- M u C o S -------------------. .- A u d i a l i t y ----------------.
| A Free/Open Multimedia | | Rock Solid, Hard Real Time, |
| Plugin & Integration Standard | | Low Latency Signal Processing |
`------> www.linuxdj.com/mucos -' `--> www.angelfire.com/or/audiality -'
.- D a v i d O l o f s o n ------------------------------------------.
| Audio Hacker, Linux Advocate, Open Source Advocate, Singer/Composer |
`----------------------------------------------> audiality_AT_swipnet.se -'


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:27 EST