[Stk] Bug in RtWvIn

[steffi at hoxel.org]

hallo,
maybe you remember my mail (see below) I send quiet a long time ago. I
recorded a sine wave with Stks RtWvIn but I got small peaks (only one
pixel was wrong) and cutoffs of more milliseconds. This happens often
at my eee-pc, but rarely on my normal pc.
Now (finally!) I found the bug in the Stk software which produces both errors.

RtWvIn uses the variable "framesFilled_" to know how many frames are
in its buffer. When the callback function puts new data in this buffer
is sets "framesFilled_ += nFrames;", when the program in function
"computeFrame()" gives a frame out it does "framesFilled_--;".
but how does this up and down counting work? first the variable is
copied, then the copy is counted up or down, then the result is
written back to the original variable.
now the following can happen:
1)---> imagine the callback thread wants to to its "framesFilled_ +=
nFrames;". it copies framesFilled_ and counts the copy up. then the
scheduler decides to stop the callback thread and gives cpu to the
program process. this wants to do its "framesFilled_--;". it copies
the variable, counts it down and writes it back. then cpu is given to
the callback thread again, which writes the counted up variable back
to "framesFilled_".
==> now the "framesFilled_--;" got lost. the program "thinks" there is
one more frame in buffer, then it is the case. so in the following it
reads one more out, which is an old one. and we get our peaks which
consists of only one wrong pixel.
2)---> now the same thing can happen the other way round. the program
wants to do "framesFilled_--;" and copies the variable and counts it
down. now callback thread gets the cpu and does its "framesFilled_ +=
nFrames;". now program gets cpu back and writes the down counted
variable back to "framesFilled_".
==> now the "framesFilled_ += nFrames;" is lost. so there are more
frames in buffer, then the program "thinks".

This "synchronization" of the two processes happens more often on my
eee-pc, since this simulated two processors. maybe the callback thread
is on the first and the rest process on the second. The chance that
the two processes "synchronization" happens is much lower on a one
processor pc.

SOLUTION
i tried the following solution, which works fine. forget the
"framesFilled_ " variable and use two buffer index variables. one for
writing frames in the buffer (for the callback thread, current write
position) and one to reading frames out (the main process, current
read position). the first variable is only written by the callback
function, the second one in the main process. to get the number of
frames in puffer, compare the two index variables.

regards, stefanie



Quoting Gary Scavone <gary at ccrma.Stanford.EDU>:

> Hi Stefanie,
>
> Both RtWvIn and RtWvOut attempt to put a blocking interface on top of
> the RtAudio callback scheme.  For robust performance, this is not
> recommended.  Use RtAudio directly instead.
>
> --gary
>
> On 22-Jan-09, at 12:50 PM, steffi at hoxel.org wrote:
>
>> Hallo,
>> thank you for your mail!
>> I thougth that in the new version of stk RtWvIn uses the callback    
>> functionality of RtAudio. Is it still blocking anywhere?
>>
>> Regards, Stefanie
>>
>>
>>
>>
>> Quoting Gary Scavone <gary at ccrma.stanford.edu>:
>>
>>> Hi Stefanie,
>>>
>>> You probably should not be using the RtWvIn class for an application
>>> that needs to be absolutely robust and run for many days or weeks.
>>> Rather, you should work directly with the RtAudio class and read your
>>> audio data via a callback.
>>>
>>> The RtWvIn class attempts to put a "blocking" front-end on top of
>>> RtAudio, using a large internal buffer.  It is not robust.
>>>
>>> Regards,
>>>
>>> --gary
>>>
>>> On 20-Jan-09, at 12:02 PM, Stephen Sinclair wrote:
>>>
>>>> Stefanie,
>>>>
>>>> Once in a while an operating system will interrupt processes because
>>>> things like disk activity need to take place, or a number of other
>>>> things.  Linux is not a "hard real-time" system, so these interrupts
>>>> can be expected.  One solution is to try running your app with
>>>> "real-time" priority.  You can set the priority to SCHED_FIFO and
>>>> hopefully the timing behaviour will be more deterministic.  You need
>>>> to run as 'sudo' to get this priority.
>>>>
>>>> Anyways, it's worth a try.  Check the "What to do" section of this
>>>> article for info on how to set thread priority:
>>>>
>>>> http://www.linuxdevices.com/articles/AT5997007602.html
>>>>
>>>> Another thing you might try is using JACK instead, and running JACK at
>>>> real-time priority.  (Which is as simple as an option in QJackCtl)
>>>>
>>>> Steve
>>>>
>>>>
>>>> On Tue, Jan 20, 2009 at 10:47 AM,  <steffi at hoxel.org> wrote:
>>>>> Hallo,
>>>>>
>>>>> I have the following problem.
>>>>> I record a 50Hz sin wave from an USB soundcard with RtWvIn in a wav
>>>>> file. Sometimes I get small peaks in the file, which come not from my
>>>>> input wave.
>>>>> When the sin has positive gradient the peaks are negative and when the
>>>>> sin has negative gradient the peaks are positive.
>>>>> For some reason the distance between those peaks equals the "period
>>>>> length" or multiple of that. With "period length" I mean the value I
>>>>> give to
>>>>> RtWvIn :: RtWvIn( unsigned int nChannels, StkFloat sampleRate, int
>>>>> device, int          bufferFrames, int nBuffers )
>>>>> in the variable "bufferFrames".
>>>>> Sometimes my program runs three days without those peaks and then they
>>>>> appear for 20 minutes or something.
>>>>> On an eee-pc with debian and ALSA version 1.0.16. this peaks appear
>>>>> quite often, while I have not seen them on my laptop with debian and
>>>>> ALSA version 1.0.12rc1.
>>>>>
>>>>> Do you have any ideas?
>>>>> Thank you, Stefanie Schmidt
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Stk mailing list
>>>>> Stk at ccrma.stanford.edu
>>>>> http://ccrma-mail.stanford.edu/mailman/listinfo/stk
>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Stk mailing list
>>>> Stk at ccrma.stanford.edu
>>>> http://ccrma-mail.stanford.edu/mailman/listinfo/stk
>>
>>