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

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?

-- 
   Olivier Guilyardi / Samalyse
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev