On Fri, Oct 17, 2008 at 8:46 AM, Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx> wrote: > 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@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
