Subject: Re: [linux-audio-dev] lock-free data structures
From: Joshua Haberman (joshua_AT_reverberate.org)
Date: Thu Jun 17 2004 - 17:43:03 EEST
On Jun 17, 2004, at 7:25 AM, Tim Goetze wrote:
> [Joshua Haberman]
>> 1. signal graph is constructed in main thread
>> 2. once audio starts, the audio thread runs the graph once for every
>> callback
>> 3. if the main thread wants to change the graph while it's running, it
>> does any heavy lifting (memory allocation, etc), then sends a message
>> to the audio thread with a lock-free queue (ex: "add this node and
>> connect it to this other node").
>> 4. buffers are passed between the disk thread and the audio thread
>> using lock-free queues
>> 5. in the real-time thread, buffers are allocated from and returned to
>> a lock-free freelist. For example, if you have a node that generates
>> a
>> sine wave, it needs to allocate a buffer when it runs to put its data
>> in. Instead of calling malloc, it asks for a free buffer from the
>> freelist.
>
> works just like the scheme i am using, with the exception that the
> graph management code is always run in the audio thread. lots of
> lock-free fifos for everything and their cousin, but glitch-free
> performance with absolutely no locks in the realtime code path is
> worth the effort.
Is this code publicly available? What algorithms are you using for
your lock-free fifos?
One thing I am still looking to learn more about is how to adjust
thread priorities and such to make sure that your threads are run often
enough (especially the disk thread), and how to decide how big your
disk buffers need to be.
Josh
This archive was generated by hypermail 2b28 : Thu Jun 17 2004 - 17:36:50 EEST