[LAD] jack ringbuffer question

lieven moors lievenmoors at gmail.com
Thu Dec 3 13:14:47 UTC 2009


Sean Bolton wrote:
> On Dec 2, 2009, at 7:33 AM, lieven moors wrote:
>> Paul Davis wrote:
>>> On Tue, Dec 1, 2009 at 9:51 PM, lieven moors <lievenmoors at gmail.com> 
>>> wrote:
>>>
>>>> I want to repeat the same Arp, until there is an update to the text 
>>>> file.
>>>> One arp is allready
>>>> loaded in each ringbuffer in main(). When the file is modified, a 
>>>> second one
>>>> is added, and
>>>> process skips to the second one. Since I have only space for two 
>>>> arps in the
>>>> buffer, there
>>>> should always be exactly one which is readable. I know it is a bit 
>>>> weird,
>>>> but it seems to
>>>> work, apart from the problem I described.
>>>>
>>>
>>> sounds as if you might want to look into atomic pointer and/or integer
>>> exchange instead, to get lock-free double buffering.
>>>
>>> ringbuffers are generally for passing streaming data/events.
>>>
>> Could you give me a hint on how to use atomic pointers?
>> Should I use __sync_val_compare_and_swap from GCC?
>> I've been looking around for other libraries, but I'm not sure where to
>> start.
>> Also, what did you mean with 'integer exchange'?
>> Is it yet another way of using CAS?
>
> All of that stuff is great to learn about, but on the other
> hand, you've already got the hang of the ringbuffer API -- why
> not just use that?  The way I usually deal with this sort of
> thing is to have two ringbuffers, one from the worker thread to
> the process thread, and one from the process thread back to the
> worker thread. Worker (inotify) thread creates a new Arp, and
> passes a pointer to it through the ring buffer to the process
> thread. Process thread then reads the new Arp pointer from the
> first ringbuffer, begins to use it, and passes a pointer to the
> old Arp back through the second ringbuffer to the worker thread.
> Worker thread then reads the old Arp pointer from the second
> ringbuffer, and frees or reuses it.
>
> Disadvantage to this is it's not quite as efficient as an atomic
> pointer exchange, but the advantage is you've already got everything
> you need right there in jack, no need for an extra library.
>
> HTH,
>
> -Sean
>
>
Thanks very much for your reply!
I was reluctant to start using atomic pointers,
because I might change the program later to
read longer sequences of Arps. So the ringbuffer approach
might be a good choice after all.
I think your idea is exactly what I was looking for.

Thanks again,

Greetings,

Lieven


P.S.
I would love to see a simple (maybe fake) example of how to use
atomic pointers though, because I only have a vague
idea of how they are used in practice... Anyone?



More information about the Linux-audio-dev mailing list