Subject: Re: [linux-audio-dev] Re: costs of IPC
From: Alexander Ehlert (alexander.ehlert_AT_uni-tuebingen.de)
Date: Sun May 13 2001 - 14:05:38 EEST
> Yes indeed! But I think you've forgotten one aspect of this IPC issue: how
> the audio system (= referring to the whole single/multi-threaded/process
> system) behaves under heavy load?
>
> As I've mentioned in my earlier message today, multiple threads means
> multiple deadlines. Even if we assume IPC has zero cost, scheduling is
> still a problem. If you have 30 threads/processes participating in the
> audio processing, that means each of those threads must get enough
> processor time during the <5ms timeframe we have...
Hi,
it's quite hard to actually follow this thread. But if you talk about
multithreading I just can't help me stating that Glame IS actually using
it and that we actually HAVE a really good backend for that purpose.
Nearly all features can be implemented as plugins that again run in
a thread, like fileoperations, effects, output to audio. The data
streaming works with sockets. Not the buffers but pointers to buffers
are send through the pipes. That allows for zero copy operations,
in case the effect/plugin works in place. I can't say how it behaves under
heavy load and I haven't tested it yet with a low latency kernel.
But I'm definitly not limited by the threads in terms off latency!
My bigger problem atm is probably having ide hardware and no low latency
kernel (btw, are there patches for 2.4 or is everyone here using 2.2?)
Anyway to get some feeling for latency, we have a test included in cglame
(the scheme backend). It sets up a ring of n-threads just copying
a buffer from thread i to thread i+1, and measuring the time it takes
for the buffer to get copied through those n plugins coming back to the
one that sent the buffer.
For the example with 30 threads on my Dual PIII-800 it takes around 780us
for a "ping". That's about 26us for a buffer to get in and out. For
300(!) threads that increases to 32us. On a Celeron 300 Laptop it takes
in total 1070us for 30 threads averaging to 35us, and looks quite worse
for 300threads ->660us averaged. But anyway you wouldn't really want
to run 300 threads. Compared to the execution time to actually process
those buffers you can neglect the time to switch between single
effect threads as long as you keep the thread count low.
BTW: Using the linuxthreads package you can use glame with
FreeBSD as well. There's even an installable package available.
Ok, anyway,
just my 2 cents, Alex
--In the space of one hundred and seventy-six years the Mississippi has shortened itself two hundred and forty-two miles. Therefore ... in the Old Silurian Period the Mississippi River was upward of one million three hundred thousand miles long ... seven hundred and forty-two years from now the Mississippi will be only a mile and three-quarters long. ... There is something fascinating about science. One gets such wholesome returns of conjecture out of such a trifling investment of fact. -- Mark Twain
This archive was generated by hypermail 2b28 : Sun May 13 2001 - 14:26:52 EEST