Subject: Re: [linux-audio-dev] LAAGA - main components
From: Jim Peters (jim_AT_aguazul.demon.co.uk)
Date: Wed May 02 2001 - 10:59:26 EEST
Paul Davis wrote:
> >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.
Okay, perhaps do it this way: put `aserver' in another thread talking
to its plugins via internal buffers. It can safely use the `estimated
sleep' method or the kill method to get itself rescheduled - just as
in your implemention of ardour that you describe below. This way it
puts the minimum system calls in the main real-time thread. If
`aserver' uses sockets for notification (as Kai pointed out), then it
is likely to be making a *lot* of system calls.
> >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.
No, I was planning on having the `song' in memory, based on a whole
bunch of sequenced blocks and sub-sections. I need it there to be
able to edit it. The stream of events needs to be generated from this
on the fly as it plays. Actually, if the song were loaded into shared
memory instead of the front-end process's memory, then the events
could be generated in real-time from that directly by a plugin.
You're right - there is no need to stream the events in, so long as I
have the song loaded into shared memory (although this also brings
some limitations).
Somehow I'm thinking of anything that goes into the real-time thread
as a plugin as somehow being `hardware'. I mean, you have to talk to
it carefully, making sure you write data to its shared memory in the
right order and taking proper precautions (just like hardware), and
the code for it lives in a restricted environment (just like
hardware). It hadn't occurred to me to implement my sequencer engine
in `hardware', but it might well be a good way to go.
> 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 :)
I quite like the purity of the approach of `no system calls in
plugins', since we need this whole thing to be absolutely rock solid.
Okay, for ardour a well-chosen system call to wake your `butler' may
be okay, but if we have 20 plugins all wanting to wake their butlers,
we are likely to be in trouble.
Another question - in this multiple-thread scenario, only the main
real-time thread runs RT_FIFO, am I right ? The others give up that
privilege and just run at a fairly high priority. Is this 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 :)
I think we may be able to get around this without a lock. This kind
of situation is why I was asking about whether writing an aligned
4-byte word to memory is atomic in an SMP environment. If so, then
your plugin-manager thread could do some kind of a double-buffering
trick. When it needs to add a plugin, it creates a new run-list (or
however you're implementing this), gets it all ready, and then updates
the `current run-list' pointer. The real-time thread reads this
`current run-list' pointer only once at the start of each loop. If
overwriting this pointer is atomic, then there is no need for locks.
This may be less clean in a kind of purity-of-coding sense, but more
efficient and less troublesome if it's done right.
Jim
--
Jim Peters / __ | \ Aguazul
/ /| /| )| /| / )|| \
jim_AT_aguazul. \ (_|(_|(_|(_| )(_|I / www.aguazul.
demon.co.uk \ ._) _/ / demon.co.uk
This archive was generated by hypermail 2b28 : Wed May 02 2001 - 11:41:42 EEST