Re: [linux-audio-dev] LAAGA - main components

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] LAAGA - main components
From: Paul Davis (pbd_AT_Op.Net)
Date: Wed May 02 2001 - 14:20:30 EEST


>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 :))

>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 ?

almost. 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).

>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.

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).

There is also the problem that the audio thread is responsible for
removing things from this list as will - it has to be, because
otherwise another thread can manipulate it while the audio thread is
traversing it. So overall, I'm not sure that this works.

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 :)

--p


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed May 02 2001 - 15:01:26 EEST