> Sounds like a very hard thing to get working efficiently... And very
> limited in usefullness. What if you're handling several stream? (Like
> multitrack audio :-) How would that be handled efficiently? If you just
> interleave the data, you'll end up with a useless structure on the disk,
> while the swap can hardly be expected to take care of you writing to
> several buffers at once.
What I was pondering here was trying to get around the normal file
system code yet still have some kind of access to the disk for dumping
large streams to swap.
This is only for the initial realtime recording of the stream, so the
data stream will grow upward linearly.
Playback is another issue and probably will involve post processing/sorting
the freshly recorded data stream to there respective tracks, etc...
I'm not sure of the implications and viability of the idea.
Writing to a raw parition probably will work without the complications
above. It seemed like a cool idea at the time I was thinking about it.
What do you think after more elaboration on the idea ?
> Not-so-critical means? Usually, audio is a bigger problem than video
> when it comes to real time scheduling jitter. 60 Hz frame rate means 17
What I'm doing is precomputed stuff. It's playback only involving MP3 or
some other compression scheme that I've got the source to.
This thing I'm writting is initially under the BeOS. It's designed to
be interact with external analog devices like a joystick and possibly
other controllers.
It's a pretty light weight app overall.
> //David
bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/