Re: [linux-audio-dev] design question for HDR

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

Subject: Re: [linux-audio-dev] design question for HDR
From: Karl W. MacMillan (karlmac_AT_peabody.jhu.edu)
Date: Mon Apr 03 2000 - 03:24:43 EEST


Do you have an example of a system that can do this currently (without
reverting to special purpose hardware)? I use the well regarded Paris
system and it has died on me doing only 8 tracks (this is on a blue and
white G3 with Ultra-2 SCSI). The system only has a single light-pipe
connection so I have not been able to record more than 8 tracks at once.
I guess my question is whether this is possible at all with current
general purpose hardware. It sounds like you are close, but it still may
be out of reach.

Karl

On Sun, 2 Apr 2000, Paul Barton-Davis wrote:

> It increasingly appears to me that Linux, even with Ultra-2 SCSI
> disks, cannot keep up the required data flow for 24 channel recording
> when the channels go to *individual files* instead of being
> interleaved.
>
> The jitter in the disk seek+read times is too great - up to a factor
> of 5, with all sorts of possible causes (other disk I/O from paging,
> buffer cache flushing, etc. etc.)
>
> Things go badly wrong when the read-ahead thread fails to keep ahead
> of the audio thread. It only takes one single mlock/read to take, say,
> 4 times longer than it normally does, and everything starts spiralling
> downhill. How come ? Well, if track N takes 4 times too long, the
> audio thread has moved along in the meantime, and used more of what
> was already read-ahead for track N+1. Thus, track N+1 also takes
> longer than it "should" (because of the extra data to read). As a
> result, track N+2 takes longer as well, and so on. Pretty soon, the
> amount of data each track needs to mlock gets larger than can be done
> within the deadlines set by the audio h/w. Then its all over. (*)
>
> There is no doubt that it could work with an interleaved data stream,
> since there would be almost no disk seeking to speak of. The
> interleaving would not have to be at the sample level, it could be on
> a block-of-samples level. Either way, we end up with files that are
> very hard to use for both varispeed and editing, whether
> non-destructive or not. Imagine cutting out a section of a single
> track. If you do it destructively, you have to rewrite the entire file
> afer the start of the cut; if you do it non-destructively, you start
> to create disk seeks for the playback-from-a-playlist mechanism as it
> has to skip over sections of the file that were cut, and then seek
> back to the start of them for the non-cut tracks.
>
> Therefore, I feel that this (interleaving) is a crazy design for an
> HDR system, even though I suspect that several existing HDR systems
> probably use it. I welcome comments and ideas since I am pretty
> confused and dispirited about what to do. Perhaps, as happens so
> often, I am just missing something obvious.
>
> --p
>
> (*) would a heuristic work here ? If the amount to read-ahead exceeds
> a certain amount, back off to a smaller amount, and hope that we
> can get back to being sufficiently ahead of the audio thread soon.
> I'll try it.
>
>
>

_____________________________________________________
| Karl W. MacMillan |
| Peabody Institute of the Johns Hopkins University |
| Network and Telecommunications Services |
| karlmac_AT_peabody.jhu.edu |
| 410/659-8297 |
-----------------------------------------------------


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

This archive was generated by hypermail 2b28 : Mon Apr 03 2000 - 03:47:07 EEST