Subject: [linux-audio-dev] Re: Realtime restrictions when running multiple audio apps .. Was: Re: disksampler ...
From: Kai Vehmanen (kaiv_AT_wakkanet.fi)
Date: Wed Jul 19 2000 - 22:19:23 EEST
On Fri, 14 Jul 2000, Benno Senoner wrote:
> What I want it to keep the the things _VERY_ simple, and arts is in my opinion
> too complex for this task.
True, aRts is already quite a big package. It's also true that most of the
time it's just easier (and faster) to write a completely new app rather
than study a non-trivial existing implementation. Also, as you can study
the old implementations, you should be able to come up with a better
design.
But you have to draw the line somewhere. We already have quite a few
esddsp style /dev/dsp wrappers, and of course, we could write a lot more.
Soon we will probably have numerous plugin-style interfaces (the current
aRts mcop-interfaces, Benno's simple soundserver, etc). A good design is
not worth much, if it never reaches usable status.
I have nothing against this development, but to be honest, my personal
interest is not in system-level optimizations. In my projects, I want to
concentrate on higher level design. Similarly in soundservers, I'm more
interested in the higher level services they could offer (how to connect
apps to each other, etc). But now that we have numerous soundserver
projects, people concentrate on the low-level side, and it'll take a
_long_ time (possibly years!) before any of the servers reach a more
mature stage.
And don't get me wrong, latency issues and performance in general _are_
important. I have to take them into account, and have to solve the
problems somehow, but it's just not something I want to focus on.
>> time. The sampler-sw project is a different thing, as we don't have any
>> existing (free) implementations at our use.
> Yes it takes time, but for now we can always pipe let's say the sound-output
> of the sw-sampler into arts using arts as soundserver , so what's the problem ?
Well, this is what we have now. Soundservers are only used via wrappers
(far from ideal), soundserver developers are pretty much on their own
(little feedback from audio app developers), etc etc ...
> I know it is much easier to implement a simple MP3 player using single
> threading like this:
[....]
> while(1) {
> read() MP3 frame from disk
> decode_MP3_frame();
> write() audio fragment to disk
> }
[...]
> rather than doing with two separate threads, one for audio and one
> for disk IO. (audio having higher priority than disk)
Using multiple threads is a more efficient solution, but IMHO, a
performance hack. I see these things as implementation details, something
that should be hidden. After all, "read+decode+write" is just what you
want to do. Instead of changing the above code, I'd probably reimplement
read() and write() to be multithreaded/non-blocking (this is what I've
done in ecasound). But, but, this is all irrelevant... Just to a reminder
that low-latency is not the only challenge you have to face when
developing usable audio apps. ;)
-- 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 .
This archive was generated by hypermail 2b28 : Wed Jul 19 2000 - 23:20:55 EEST