Re: [linux-audio-dev] Re: Realtime restrictions when running multiple audio apps .. Was: Re: disksampler ...

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

Subject: Re: [linux-audio-dev] Re: Realtime restrictions when running multiple audio apps .. Was: Re: disksampler ...
From: Kai Vehmanen (kaiv_AT_wakkanet.fi)
Date: Thu Jul 20 2000 - 13:10:39 EEST


>>> read() MP3 frame from disk
>>> decode_MP3_frame();
>>> write() audio fragment to disk
>> want to do. Instead of changing the above code, I'd probably
>> reimplement read() and write() to be multithreaded/non-blocking
> This can only work reliably if you extend the read()/write() API
> with guaranteed bandwidth features and a prepare() operation, so
> that something outside your application can do the necessary
> buffering.

Actually, this is just a way to separate implementation from the
design. I have a FILE_IO class, which has above read() and write()
functions. My app uses this interface. What happens on the
implementation level is another thing. Basicly I have subclasses
FILE_IO_STUPID and FILE_IO_CLEVER which actually implement the
read() and write() functions. The first class simply uses fread()
and fwrite(), while the second one launches a disk butler thread and
does more intelligent disk i/o.

This is a common OO-design. I can write apps and ignore implementation
details. I can also change the implementation without affecting other
parts of the program.

> OTOH, you'll need to centralize disk access anyway to deal with more
> than one stream per HD efficiently, so the more complex API will

And this is just what I have done. I just want to keep the complexity
hidden. If you get carried away, and mix threads, scheduling, etc with
higher level design, your program will end up being a very complex,
unmaintainable beast. ;)

Of course, in some cases you really should just hack away. I've been
doing lots of kernel-space programming recently, and I admit, it's a
different ball game. When you have under 10000 lines of code,
maintaining these hacks is not a problem. But unfortunately most
(interesting) audio apps are big projects, and sw design issues become
very important.

--
Kai Vehmanen <k_AT_eca.cx> ----------------- CS, University of Turku .
 . audio software for linux ...	http://www.eca.cx 		  .
 . armchair-tunes mp3/wav/ra .. http://www.wakkanet.fi/sculpscape .


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

This archive was generated by hypermail 2b28 : Thu Jul 20 2000 - 12:34:24 EEST