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@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
