[Stk] peaks in sin wave

[Stephen Sinclair]

It still sounds to me like it could be related to buffer timing.  I
have no idea why you'd get strange data in the signal, but perhaps an
undetected buffer underflow is happening.  I would try really setting
the scheduler to SCHED_FIFO as I suggested (not the same as using
nice), and also playing with the number of buffers, and try different
permutations of your configuration.  For example, does it happen with
only 2 channels? with 1 channel?  At different sample rates?  How
about while using JACK instead of ALSA?  It would be nice if you could
narrow it down further with more testing.  There is a certain amount
of buffer manipulation that may be occurring in the ALSA
implementation, so if there is really a software problem and you can
find any errors in there it would be great.  Perhaps you could figure
out how to detect your "peak" and trigger the debugger in that case,
it might help find problems in the code if there are any.

Steve

On Wed, Jan 21, 2009 at 4:02 AM,  <steffi at hoxel.org> wrote:
> Thank you for the quick answer.
> I tried to start the program under root with nice -18, but the same peaks
> occured.
> I forgot something to say before, it is only one sample which produces a
> peak.
> I tried different sizes of "bufferFrames" and the distances between the
> peaks are exactly of "bufferFrames" size and sometimes multiples.
> My soundcard has four channels. When I but the input sin on the first three
> and nothing (zero) to the fourth, I get the peaks on the first three on the
> same place, but no peak on the fourth channel.
> I catched all errors and warning Stk gets/produces about buffers and the
> input stream and exit the program if one of those accures. But the program
> produces the peaks and is still running.
>
> Stefanie Schmidt
>
> Quoting Stephen Sinclair <sinclair at music.mcgill.ca>:
>
>> 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
>>>
>>>
>>>
>>
>
>
>
>
>