linuxaudio.org

On Fri, Oct 17, 2008 at 8:46 AM, Paul Davis  wrote:

quoted text
> On Fri, 2008-10-17 at 14:13 +0200, Olivier Guilyardi wrote:

>

>> Okay, I wrote such a test. It fails with Jack's ringbuffer (jack1 r3004) but

>> succeeds with Portaudio's one (r1240).

>

> Nice work. Nobody ask why we didn't do this 5 years ago!

>

>> The Portaudio code looks more and more robust to me. It's also surprisingly

>> short. Maybe that the best would be to replace jack's ringbuffer with it? I

>> think it should be possible to keep the jack_ringbuffer api unchanged.

>

> I'd rather add the memory barriers to the JACK code, but this could be a

> race to see who does what first. A memory barrier is typically single

> instruction. The complication tends to be defining them in a

> sufficiently portable way.

>

Why do you suspect you need memory barriers?  My concern with

ringbuffer.c is the non-atomic ops on the read and write pointers.

They're marked volatile, but what I think you really want is make all

ops on those fields atomic.  Stuff like this:
rb->read_ptr += n1;

rb->read_ptr &= rb->size_mask;
Looks like a problem to me.  What happens if there's a context switch

in between those 2 statements?
NB: I only took a cursory glance at the code.

_______________________________________________

Linux-audio-user mailing list

Linux-audio-user@lists.linuxaudio.org

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