Subject: Re: [linux-audio-dev] munlock and mmap
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Wed Apr 05 2000 - 06:17:00 EEST
>A pseudo code attempt using read.
I went through a version quite a lot like this, using what I called a
DoubleBuffer.
The problem with this kind of scheme, as with Benno's sample code, is
that it doesn't take capture/record into account.
When we punch into record mode, we (may) have to do a cross fade with
the existing material (and also when we punch out). But not the
*current* existing material - stuff from several msecs earlier. We
also have to write the recorded data back to a point in the file that
before the current playback position (*)
This means that you have to keep more data around, and do some careful
pointer keeping, which may appear to be no big deal.
But keep in mind that we aren't always recording, and when we do punch
in, it may be in the middle of a chunk of read-ahead
material. Likewise for punch out. This can get pretty complex pretty
quickly.
This isn't impossible to do by any means, but trying to do it
*efficiently* is hard. I'm trying to do it efficiently, since it was
clear to me from the start that the "right" design is elusive, and I
don't want to have to come back and try this again at a later
date.
BTW: I've been very gratified by the results of OO design here -
despite having done about 6 significantly different implementations of
the read-ahead/write-behind code, the changes to the rest of the code
are either zero, or minimal. I tweak the ARDOUR::Track::read_ahead()
and ARDOUR::Track::write_behind() methods, maybe a little alteration
to the ALSA::MultiChannelDevice::{write,read}_{to,from}_channel()
methods, and thats about it.
--p
(*) an alternative, i suppose, is to use a playlist right from the
word go, and always store overdubbed material in a different file.
Then just fix up the playlist to reflect its location. However,
this doesn't change the fact that recorded stuff is not just being
written into the same buffer that we're currently reading from. It
also ruins the goal of being able to (at least optionally) record
directly into some "standard audio file format".
This archive was generated by hypermail 2b28 : Wed Apr 05 2000 - 05:52:35 EEST