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

[Olivier Guilyardi]

Olivier Guilyardi a écrit :
> Hi,
> 
> Pieter Palmers a écrit :
>> Sean Bolton wrote:
>>>
>>>> test-bit-circle-jack - starting (5s max) - buffer size: 512
>>>> || FAILURE: 2 != 514
>>>
>>> I thought it suspicious that 514 = 2 + 2 * 256, while on a PPC it  
>>> returns
>>> FAILURE: 2 != 0.  Endianness bug? No, but it's a clue...
> 
> Do you have a PPC? Which one? Can you please paste the whole output of 
> "make test"?
> 
>>> I don't think you're seeing a *bug* in the jack ringbuffer, just a  
>>> difference in
>>> semantics between it and the PortAudio and lfq imlementations.  Both PA
>>> and lfq mask the index after reading it, so they can completely fill  
>>> the buffer.
>>> The jack implementation masks the stored index, which means it can't
>>> ever completely fill the buffer, or there would be an ambiguity as 
>>> to  whether
>>> it was full or empty.  The most it can store is (size - 1) bytes.
>>>
>>> In the jack version of your code, at some point, the buffer almost  
>>> fills, and
>>> jack_ringbuffer_write only writes a single byte to the buffer (low  
>>> order on x86,
>>> high order on PPC).  Next time around, it does this again.  Then the  
>>> following
>>> thread reads, not 0x0002 like it should, but either 0x0202 (x86) or  
>>> 0x0000 (PPC).
>>>
>>
>> I can confirm this, since the following will make the test 'succeed', 
>> although it results in a very slow progress once the buffers are full.
>>
>> Index: test-bit-circle.c
>> ===================================================================
>> --- test-bit-circle.c   (revision 314)
>> +++ test-bit-circle.c   (working copy)
>> @@ -50,6 +50,9 @@
>>
>>      if (value)
>>      {
>> +      while(jack_ringbuffer_write_space(rb[1]) < 2) {
>> +        usleep(1000);
>> +      }
>>        jack_ringbuffer_write (rb[1], (char *) &value, sizeof (uint16_t));
>>        value = 0;
>>      }
> 
> I know my code performs much more write than read operations, I did that 
> on purpose, while playing with it.
> 
> Now, back to reality, let's say that you have a thread that synthetizes 
> some sound, puts it into a ringbuffer, for an audio thread to read and 
> play it. Let's also say that the synth thread performs much faster than 
> the audio thread, so that the buffer is almost always full. I think this 
> is quite realistic.
> 
> In these conditions, if I understand correctly the result of this test, 
> there is a chance for the output of the ringbuffer to differ from its 
> input. Isn't that some sort of bug?
> 

Hmm, wait, I think I understand your point.. With the Jack implementation, in a 
buffer of 16 bytes, you can really put 15 bytes. I didn't notice this. And since 
I do not check if there's enough space to write my 16-bits integer, when the 
buffer is almost full, it only writes one byte...

So, well, yes it looks like this is no bug... Sorry about confusion.

I've fixed this (r315). This test now indeed passes on all backends.

What about the test-int-array-* family of tests on PPC?

-- 
   Olivier Guilyardi / Samalys