[Sumover-tech] RAT - artifacts in sound output
Linus Lüssing
linus.luessing at web.de
Tue Aug 31 13:15:58 BST 2010
Hi Piers,
On Tue, Aug 31, 2010 at 10:41:36AM +0100, Piers O'Hanlon wrote:
> 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.
Ah, hehe, that worked now, thanks. Guess I didn't read the
rat/README.debug close enough ("RAT is dependent on the UCL common
library [...], it is imperative that the common library should be
configured with the same options as RAT for those options to work correctly.")
>
> > 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....
Yep, did that in the first place but it did not help.
>
> > 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.
I commented out the following block, which removed the artifacts in the
audio output nearly entirely:
-----
1182 /* if (!snd_pcm_status_get_avail_max(status)) {
1183 debug_msg("Resetting audio as statusmaxframes is zero\n");
1184 err = snd_pcm_prepare(current.rx.handle);
1185 if (err<0) debug_msg("Failed snd_pcm_prepare in audio_ready");
1186 err = snd_pcm_start(current.rx.handle);
1187 if (err<0) debug_msg("Failed to re-start in audio_ready");
1188 //dump status
1189 //snd_pcm_status_dump(status, output);
1190 //frames= snd_pcm_avail_update(current.rx.handle);
1191 debug_msg("audio_is_ready: snd_pcm_avail_update(current.rx.handle);: %d\n", snd_pcm_avail_update(current.rx.handle));
1192 debug_msg("audio_is_ready: %d bytes (bytes per blk %d)\n", avail, current.bytes_per_block);
1193 } */
----
I just have occasionally single "In SND_PCM_STATE_XRUN - preparing audio"
about every 15-25 seconds.
Making the buffer a little smaller with RAT_ALSA_BUFFER_DIVISOR set to 50
instead of 60, I get that XRUN every second. So I guess the value of 60
is already pretty much the optimum for the hardware here.
The example here http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2pcm_8c-example.html
uses a xrun_recovery() on XRUNs, maybe that's better than re-preparing the
audio device again and might work for the sound devices where the audio
would break on an XRUN without repreparing?
I now also noticed that I don't seem to be able to do any recording (with or
without removing the lines stated above) in Alsa default. With OSS and selecting
11kHz, DVI, 8 Units on all devices, recording works fine. When trying to use Alsa
default, I get the following debug output when releasing the right mouse button
and stopping the recording with that (don't know if that helps, anything weird
about it?):
-----
[pid/22564 +920 mbus.c] received reliable msg 87, sending ACK
[pid/22564 +1138 auddev_alsa.c] iport_get 0
[pid/22564 +1145 auddev_alsa.c] Get iport count for 0 (num=5)
[pid/22564 +1153 auddev_alsa.c] iport details ad=0 idx=0 : Capture (Enabled=1)
[pid/22564 +774 auddev_alsa.c] Get igain 0
[pid/22564 +983 auddev.c] GAIN=68
[pid/22562 +920 mbus.c] received reliable msg 216, sending ACK
-----
(should igain be something else then 0?)
Thanks for your support again and so far.
Cheers, Linus
>
> 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
> >
>
More information about the Sumover-tech
mailing list