linuxaudio.org

On Tue, 2008-10-14 at 23:00 +0200, Olivier Guilyardi wrote:

quoted text
> Kjetil S. Matheussen wrote:

> > Olivier Guilyardi:

> >>

> >> For inter-thread communication there's Portaudio's ring buffer:

> >> http://portaudio.com/trac/browser/portaudio/trunk/src/common/pa_ringbuff...

> >>

> >> It can easily be used out of Portaudio (I'm currently doing that), and it

> >> features memory barriers [1] which AFAIK Jack's ringbuffer doesn't.

> >>

> >> One problem with everything Portaudio is this heavy naming scheme. For a simpler

> >> API, you might like my little wrapper:

> >> http://jackbeat.samalyse.org/browser/jackbeat/trunk/src/core/ringbuffer....

> >>

> >

> > Nice. It's probably quicker to copy the jack_ringbuffer.c file out of jack

> > though.

>

> This isn't the same as Jack's ring buffer. It's a little wrapper around

> Portaudio's ring buffer, which as said above, features memory barriers. Jack's

> ring buffer has no memory barrier AFAIK.

it doesn't, but it would be nice if someone would add them. i don't know

why people feel the need to be snarky about the "oh-so-famed JACK

ringbuffer" ... its famed only because when we first implemented it

nobody in the LAD community could find an open source implementation of

the idea. i don't believe anybody has ever claimed that its the bees

knees of lock-free ringbuffers (and if they did, they don't know what

they are talking about). lennart also claims that the JACK

implementation is borked because of "misuse of volatile". it would be

nice if that was fixed too. 
another detail about the JACK ringbuffer model: yes, within JACK it is

used in a way that involves copying data. thats because you cannot give

a hardware device a pointer to your app's memory and expect it to be

useful (certainly not if you want to mix streams). many other situations

use a ringbuffer in a way that *doesn't* involve copying - you get the

address(es) of where you can read/write in the buffer and then

read/write from/to there, rather than any intermediate buffers. for

example, within ardour, file i/o is done directly to/from the

ringbuffer. yes, the API provides read/write methods that copy to/from

some other buffer, but these are convenience methods that turn out to

model the way that quite a lot of code wants to operate.
i'm about to release the next jack(1), complete with 64/32 host/client

support, and it would be cool to remove the longstanding memory

barrier/volatile buglets from the library.
--p
_______________________________________________

Linux-audio-user mailing list

Linux-audio-user@lists.linuxaudio.org

http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user