Subject: Re: [linux-audio-dev] more audio client/server considerations (client acts as engine)
From: David Olofson (audiality_AT_swipnet.se)
Date: to loka 14 1999 - 19:57:54 EDT
On Thu, 14 Oct 1999, Benno Senoner wrote:
> I think the ideal solution is still to have point to point communication between
> clients (audio applications) and the audio server.
Too restrictive to be the only supported method, but yes, it should
definitely be the recommended way of writing applications that could
be useful in low latency cooperation with other applications.
It means the engine will have to be fast and flexible, but hey, if
it's not good enough, hack it and submit the patch! :-) But of course,
people will still limit the low latency performance of the whole
system by writing local engines. We just have to live with that,
until MCS is so tuned and computers so fast that it makes no sense
not to use it... Another order of magnitude heavier DSP, and the way
you move the data around is virtually irrelevant WRT performance, so a
few % worse than hard core custom shm IPC won't matter, if it brings
some advantages.
Oh, well; Marxism never worked too well either...
> there could be two classes of clients:
> 1) the client process the audio/event data and hosts plugins in his own
> thread, and sends only the final result (audio data / MIDI events) to the audio
> server which mixes together/routes the data from/to the clients.
>
> 2) the client delegates most of functions to the engine,
> the plugins are hosted in the engine thread, that means
> audio data from the client is sent to the server and then processed by the
> plugin net of the engine, and then mixed/routed as with the clients in the 1)
> case.
Two nice ways of doing it, 2) being the superior one WRT cooperative
system performance. 3) would be streaming data back and forth as you
pointed out will result in latency problems. However, 3) might be
very useful if you really want to use that cool application with
run-time compiled processing nets running in the application's engine,
or whatever, for processing some tracks in your HDR program. A few ms
of extra latency is far better than having to export/process/import,
or some other medieval high-tech solution... :-)
> Now an additional question:
> David said "sensor threads" should run at highest priority (to allow to preempt
> the engine), to get accurate timestamping.
>
> IMHO it would be better to run all timestamp sensitive sensor tasks (MIDI input
> etc) in one single thread to reduce scheduling overhead.
AFAIK, it doesn't make a difference, except when multiple input
events occur at the same time. Sleeping threads are not checked by
the scheduler anyway... And packing multiple (unrelated) device
interfaces in one thread isn't exactly nice coding style.
> So what would be a typical figure of the running threads in an enviroment
> with MIDI in/out , PCM in/out , server engine, and one client app ?
>
> threads sorted by priority , highest priority first
>
> MIDI i/o thread :select()s on MIDI fds and reads/writes data to the event
> system
> server engine : read()/write() of PCM data, syncs with clients, processes
> plugins and mix results toghether
> client app: reads/writes PCM data/event data from/to the engine
> (and of course does some processing on the data).
>
> Note that with this priority scheme, a flawed MIDI out as the one on the
> SB AWE64, could cause audio dropouts on the audio engine, since the
> MIDI out driver does busywaiting.
Uuurgh!! Amazing they still build that kind of crap. RTLinux can "fix"
it, but that's certainly *NOT* what it's meant for!
> But we assume that we run our engine on non-flawed hardware.
Yep. Rock solid, low latency audio with high accuracy MIDI input is
probably rather uninteresting to people that don't even want to pay a
few $ for a card with a decent MIDI interface. (Ok, throw in a low
prio, high jitter MIDI sensor thread for crappy sound cards if you
like... Better than the engine freaking out first thing for every
other Linux newbie.)
//David
·A·U·D·I·A·L·I·T·Y· P r o f e s s i o n a l L i n u x A u d i o
- - ------------------------------------------------------------- - -
·Rock Solid David Olofson:
·Low Latency www.angelfire.com/or/audiality ·Audio Hacker
·Plug-Ins audiality_AT_swipnet.se ·Linux Advocate
·Open Source ·Singer/Composer
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:59 EST