[Sumover-tech] RAT - artifacts in sound output
Linus Lüssing
linus.luessing at web.de
Tue Aug 31 09:57:41 BST 2010
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?).
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
-----
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.
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
More information about the Sumover-tech
mailing list