Subject: Re: [linux-audio-dev] hdr disk throughput
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Tue Mar 14 2000 - 10:45:43 EST
>As far I can understand you have N channels playing, and you want
>instantly switch some of these channels (up to N if you want) in the
>record mode. That means if you don't have 24 channels playing AND
>recording all the time. And since you don't need sustained double
>performance, but only when switching some channels from/to
>recordmode/playmode, your problem is easily solved by buffering.
Wrong! Because we could switch *back* to playback from capture at any
time, and we *have* to do it with zero audible latency, we always have
to have the playback data in the read-ahead buffer.
So you're right that we don't have to sustain double performance all
the time, but we do have to do it for every track that is currently in
record mode.
>With buffers large enough, the application will easily be able
>to buffer new recording channels into mem, and as soon the
>track is out of the playback mode, the disk thread can begin the write
>to the disk. (or you could even overlap the times, since the buffer
>will overcome to the momentarily performance lack of the disk).
Sure, thats what I do now. But this doesn't work (or I can't see how
to make it work) for the reverse transition (capture->play)
>PS: what kind of enhancements do you plan for ardour's buffering scheme ?
>(you talked about it in your other mail)
>I can't recall your initial punch-in/out problems ? application stalls ?
No, the punch in/out problem is a real technical issue. Professional
recorders do not just start writing the new samples straight at the
punch in point and stop at the punch out point. They do a cross fade
whose length (and sometimes shape) is configurable. This allows you to
punch in/out of a track in the middle of an musician's playing without
getting a click on the recording. But to do this, you need both the
new samples *and* the old ones.
Thats why these two problems are really just variants on the same
thing. I need to shift my mental picture of what ardour does.
I have been thinking of it as a 2-state device for each channel -
either recording or playback. Instead, it needs to be a device that
always does playback, but sometimes does capture(+cross-fade mixing)
as well.
>Can you explain us again what is still needed to make adrour
>satisfy all your pro-studio needs ?
>:-)
Well, the big problem after dealing with the issues discussed above is
that of recording different takes in some sensible way. And then, the
big one: hooking it up with a non-destructive, non-linear editor. I
have already more or less decided that I will use snd for this, though
it may take some butchering to get them to fit nicely together.
There is also implementing MMC as part of libmidi++, but thats not
much more than a days worth of work, judging from my copy of the MIDI
reference documentation.
>BTW, how long does take a random seek in ardour at 24 tracks:
>ie: when you seek from the begging to the middle, how many
>secs (or fractions) pass until you can hear the audio again ?
>just curious :-)
i haven't measured it, but a rough guess would be 0.5 to 1 second. The
transport control logic doesn't let you go directly from
play->rewind->play again, which I should change, but the LED's do
indicate then the seeking has stopped.
--p
This archive was generated by hypermail 2b28 : Tue Mar 14 2000 - 18:47:11 EST