Re: [LAU] Simple, easy multithreaded circular buffer library for Linux?

On Tue, 2008-10-14 at 23:00 +0200, Olivier Guilyardi wrote:
> 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_ringbuffer.h
> >>
> >> 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.h
> >>
> >
> > 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@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
Received on Wed Oct 15 12:15:01 2008