Subject: Re: [linux-audio-dev] LAAGA - main components
From: Paul Davis (pbd_AT_Op.Net)
Date: Wed May 02 2001 - 02:30:30 EEST
>I'd need to understand more about the details of this `aserver' and
>`pcm_shm' stuff to understand, but if this looks good to you, I'm
>willing to go along with it. How does `aserver' solve the problem of
>unblocking waiting processes without making any system calls ?
it doesn't, which is a problem that would need to be solved. remember,
aserver isn't written to avoid that problem at this time.
>> Let me give you a scenario where this fails pretty badly by my
>> standards. Suppose your GUI displays and allows you to control the
>> parameter values of some kind of FX (even just gain). Every time you
>> move the fader or whatever widget it is, there's 100ms of audio
>> already generated and sitting in the buffer waiting to be
>> played.
>
>Hold on - in my app the plugin is generating the audio, not the
>external process. If I have real-time control stuff like that going
>on, I'd be writing it straight into shared memory, so it would happen
>as soon as the GUI process received the mouse-movement. The 100ms
>delay only applies to getting audio into the plugin that it can't
>generate itself.
OK, understood. Its just that I doubt very much that you'd do that
(given my observations about using threads instead).
>If this aserver-plugin idea works, then everything is taken care of.
>This supports both input and output of audio, right ? So aRts could
>patch in at any point in our plugin network (with a largish fixed
>latency) ?
i think so.
>There are still some situations that will require shared memory
>buffers (rather than simple shared memory parameter structures). For
>instance, a sequencer might be having to stream a list of events to a
>plugin via a shared memory segment.
what kinds of events? if they come from, say, a standard MIDI file,
then again, i'd imagine using a thread to get them.
>You still have to solve the problem of how to have one thread wait for
>the main real-time thread when internal buffers become full or empty,
>without putting system calls in the main real-time thread. How did
>you solve this in ardour ? A short-duration sleep ?
i cheat :)
the butler thread (responsible for disk i/o) is woken using
pthread_cond_signal(). in theory, this need not be a system call, but
in practice it involves using kill(2), since there is no other way to
do this on a Linux system.
you can avoid this by using the RTC or usleep(2) in the butler thread,
since it has a long, long time to sleep between doing any work (ardour
buffers about 1 second of audio from disk, and reads/writes in chunks
of 256kB; configurable)
if i ever detect the pthread_cond_signal being a problem, i'll use the
second method. its possible that i might even have left the code in
place for that. we send the kill only when the data needed or space
available in at least one disk stream has reached some threshold. but
yeah, you can call me a hyprocrite if you want :)
if i sound harsh about system calls, its not because you can't ever
get away with them. its because its better to be thinking you are in
an interrupt, and you have to do everything right there, with no "out
of context" assistance. if, even after thoroughly immersing yourself
in that mindset, there's no way to avoid a system call, then what must
be must be :)
>Another thought - if you are using threads, then you could have a
>thread responsible for loading new plugins. This would mean that
>loading a new plugin, allocating memory for it and so on could all
>happen without disturbing the real-time thread in any way (which is
>running live), and then the plugin just needs to be linked into the
>run-list somewhere, and off it goes. This problem had been lurking in
>the back of my mind - I think threads solve this, am I right ?
yes, now you're getting the idea :)
in AES, its the GUI thread for AES that takes care of all this. the
plugin itself gets initialized() from within that thread, and when its
ready, it calls engine.attach (this); this call may potentially cause
the audio thread to skip a single engine cycle (say, 64-128 frames)
(since we need a lock to protect the list of plugins), but the chances
of it doing so are fairly small, and besides, i think of it as
equivalent to the analog "click" when i connect things into my analog
patch bay :)
--p
This archive was generated by hypermail 2b28 : Wed May 02 2001 - 03:07:46 EEST