Subject: Re: [linux-audio-dev] LAAGA - main components
From: Jim Peters (jim_AT_aguazul.demon.co.uk)
Date: Thu May 03 2001 - 12:38:43 EEST
Paul Davis wrote:
> >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.
>
> good point. i'll switch to using the wakeup method for the butler when
> i can. there is, however, another example of the same kind of issue
> with transport state changes. these can't be done from within the
> audio thread (too much work to get done), but they must be initiated
> from there (for sync reasons). so whenever ardour's transport state
> changes, we also have to do some pthread-related stuff. this one isn't
> possible to do in the same way, but i'll think it again about now that
> i'm feeling guilty :))
I guess we could find a good way to manage the `kill' calls if this is
really necessary. If we hide this behind a couple of function calls
then we can control it and change the implementation as necessary.
For a start, saving up the calls and dispatching them at the end of
the loop takes away a big chunk of the risk of disrupting the audio.
However there may be another way of approaching this. We could have a
call "submit_job(funcp, voidp)" which adds a job to the end of a
job-list which is processed serially in another thread managed by the
server. So occasional jobs that it's not worth having a whole thread
to handle can be set to run by the real-time thread, to be executed a
short time later in another parallel thread.
If this fits in naturally with other things then maybe its a good way
to go. If not, maybe forget it. We would have the plugin management
thread constantly ticking over anyway, wouldn't we ? Perhaps that
could handle these jobs.
Note that this job-queue idea would only apply to occasional jobs that
take some time but don't block. For tasks that may block, like
streaming to/from other processes or to/from disk, having a separate
thread and regular sleeps makes more sense, I think.
> i'll think about this. what you're describing is somewhat like the
> compare-and-swap instruction implemented by most current
> architectures, which is very useful for multithreaded programming, but
> without the full semantics of that operation. Something from my days
> of working on large-scale SMP systems is nagging me that this doesn't
> work without the use of the compare-and-swap instruction, but it might
> be OK, since we never need to do a compare.
>
> Oh, there is the problem that such writes are not atomic on all
> architectures (SPARC being the foremost example; I'm not sure about PPC).
When I say `atomic' what I'm trying to ask is if it is possible to do
a 32-bit read half-way through the 32-bit write, and get a scrambled
result, neither the original value nor the new value. I guess the
instruction itself doesn't have to be an atomic operation, just the
memory write. I would guess that for all systems with a 32-bit bus to
memory, this will be atomic. Is this true ? (What's this about SPARC ?)
That's all I would need to use the technique I have in mind. But
if it isn't true it's not the end of the world - it just makes the
technique slightly less clean to code.
In my plan, only one process (or thread) would be writing to this
location, and all the others will be treating it as read-only, so we
don't have the problem of two processors competing to do an operation
- which is what test-and-set instructions were designed to handle (I
think, and which I'm guessing is somehow similar to compare-and-swap).
Some time ago Abramo wrote this:
> As an example, I remember well that you (Paul) in past has "bet" with me
> that it would be impossible to build a general purpose non-RT meter
> plugin in alsa-lib without to screw RT properties of main thread.
>
> Now in alsa-lib we have such a piggy and almost nobody as noted it and
> the same lock less trick will be probably used in Linux kernel for SMP
> performance metering.
Abramo - what is this technique ? It may be close to what I have in
mind. It would be interesting to know in any case.
Paul, in ardour you say you're using some kind of lock to protect the
list of plugins. I'm curious to know how this locking works
internally. Perhaps I'll take a look at the pthreads source when I
get a chance.
Paul wrote:
> But as I said, I get a small click most times that I plug analog gear
> together, and I don't see this as any different :)
It'd be nice to get it right, though.
> ardour also has the option of an additional RT_FIFO thread for
> handling MIDI sequencing. it sleeps on the RTC interrupt (running at
> 4kHz typically, to provide perfect MIDI timing). but yes, all other
> threads are non-RT threads and in fact, they don't even run at high
> priority (so far).
Thanks for that. I've had a look at the ardour pages, and this is
impressive ! I'm currently half-way through a Sound Engineering
course, and we're using the Mackie d8b, so I can really appreciate
what you're doing here.
I'm wondering if now is the moment to take a step back and figure out
where we've got to and where we're heading, but I'm going to start a
new thread for this, because the current thread has gone off the RHS
of my screen.
Jim
--
Jim Peters / __ | \ Aguazul
/ /| /| )| /| / )|| \
jim_AT_aguazul. \ (_|(_|(_|(_| )(_|I / www.aguazul.
demon.co.uk \ ._) _/ / demon.co.uk
This archive was generated by hypermail 2b28 : Thu May 24 2001 - 00:28:09 EEST