[Sumover-tech] RAT - artifacts in sound output

[Piers O'Hanlon]

Hi Linus,

On 31 August 2010 09:57, Linus Lüssing <linus.luessing at web.de> wrote:
> Hi there,
>
> it's me again :). I think I could track down the issue a little
> further. First I did a 'sed "s/debug_msg(/printf(/" *.c *.h' as
> the 'make clean && ./configure --enable-debug && make"' did not
> seem to work (am I missing something obvious?).
>
Yes it's a bit tricky but to use debug_msg() you need to configure and
build common with  --enable-debug as there is where it comes from. The
configure --enable-debug for RAT and you should get them printing.

> Then I noticed a lot of these lines with the Alsa default device:
> -----
> In SND_PCM_STATE_XRUN  - preparing audio
> Resetting audio as statusmaxframes is zero
> audio_is_ready: snd_pcm_avail_update(current.rx.handle);: 0
> audio_is_ready: 0 bytes (bytes per blk 320)
> In SND_PCM_STATE_XRUN  - preparing audio
> Resetting audio as statusmaxframes is zero
> audio_is_ready: snd_pcm_avail_update(current.rx.handle);: 0
> audio_is_ready: 0 bytes (bytes per blk 320)
> In SND_PCM_STATE_XRUN  - preparing audio
> Resetting audio as statusmaxframes is zero
> audio_is_ready: snd_pcm_avail_update(current.rx.handle);: 0
> audio_is_ready: 0 bytes (bytes per blk 320)
> In SND_PCM_STATE_XRUN  - preparing audio
> Resetting audio as statusmaxframes is zero
> audio_is_ready: snd_pcm_avail_update(current.rx.handle);: 0
> audio_is_ready: 0 bytes (bytes per blk 320)
> In SND_PCM_STATE_XRUN  - preparing audio
> -----
>
Unfortunately it seems some audio devices seem to go into state XRUN
quite often despite buffer sizes. RAT just resets the audio everytime
it goes into XRUN - otherwise the audio just stops. The documentation
on ALSA API isn't good so coding with it is a bit of trial and error.
I have spent quite some time tweaking the order and parameters to the
ALSA calls but I can't seem to get it working much better than it
does.

You can try playing with the size of RAT_ALSA_BUFFER_DIVISOR in
auddev_alsa.h  to see if it helps....

> So looks like something gets reset a little too often, right?
> Just for testing, I commented out the last, large if-block in
> alsa_audio_is_ready() of auddev_alsa.c as this is the one
> producing these weird resets.
>
Which lines are you referring too? On some cards it seems if it's not
reset then it just stops.... It's hard to know exact when to not use
it - if you can find some function that knows if a reset after an XRUN
is or is not necessary that would be great.

Thanks,

Piers

> And hey, then these annoying artifacts are gone! But I guess just
> removing this if-block is not a valid fix for this bug, right?
> Anyone a little more familiar with this alsa-api than me?
>
> Cheers, Linus
>
> On Mon, Aug 30, 2010 at 06:26:37PM +0200, Linus Lüssing wrote:
>> Hi there,
>>
>> What do you guys think? Does it still sound like the
>> soundcard is just not going to work? Or is it just a "simple" bug
>> or mistweaked parameter?
>>
>> Is there anything else you think might be worth testing?
>>
>> I think I had quite similar noises when I was having a look at
>> Jack/Jack-Rack/Audacity a year ago. I had to increase some buffers
>> and values to get rid of this noise, increasing the latency as a
>> trade-off instead.
>>
>> I found some old config options in qjackctl, which worked back
>> then (but can't verify them now):
>> Realtime: y (all others, no)
>> Frames/Period: 512
>> SampleRate: 48000
>> Periods/Buffer: 4
>> Port Maximum: 256
>> Timeout (msec): 1000
>> Start Delay (secs): 5
>> Audio: Duplex
>>
>> Could someone point me to the right variables in the code so I
>> could try similar tweaking in rat, too?
>>
>> Cheers, Linus
>
> _______________________________________________
> Sumover-tech mailing list
> Sumover-tech at cs.ucl.ac.uk
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/sumover-tech
>