Getting XRUN after writei in RUNNING state?

Getting XRUN after writei in RUNNING state?

[Piers O'Hanlon]

Hi folks,

I've trying to improve the ALSA driver for the Robust Audio Tool (RAT) tool:
http://frostie.cs.ucl.ac.uk/nets/mmedia/wiki/RatWiki

Specifically the code I'm talking about is:
http://frostie.cs.ucl.ac.uk/nets/mmedia/browser/rat/trunk/auddev_alsa.c

I've added some status dumps in the code that I'm running which aren't
in the repository version but basically the code is doing the same thing.

However I'm seeing weird XRUNs (under runs on the playback side) -
There's as couple of instances I don't understand: (The pcm device setup
is shown at the bottom);

1) RAT is happily writing audio to the playback device for while then
the device just seems to go in XRUN state after being in RUNNING state
and doing a writei()??:

[+945 auddev_alsa.c] Time since last write: 42734us, Trying to write 640
frames
  state       : RUNNING
  trigger_time: 1194622844.333930000
  tstamp      : 0.000000
  delay       : 121
  avail       : 1927
  avail_max   : 2043
[pid/9901 +954 auddev_alsa.c] Wrote 1280 bytes, frames: 640
  state       : XRUN
  trigger_time: 1194622844.333930000
  tstamp      : 0.000000
  delay       : 758
  avail       : 1290
  avail_max   : 2046

2) RAT is writing audio to the playback device for while then the device
just seems to go in XRUN state when there's still positive delay in the
buffer.

Here's last write that went ok - showing the snd_pcm_status_dump before
doing the write and afterwards:

[+945 auddev_alsa.c] Time since last write: 42635us, Trying to write 640
frames
  state       : RUNNING
  trigger_time: 1194622843.886113000
  tstamp      : 0.000000
  delay       : 275
  avail       : 1773
  avail_max   : 2041
[+954 auddev_alsa.c] Wrote 1280 bytes, frames: 640
  state       : RUNNING
  trigger_time: 1194622843.886113000
  tstamp      : 0.000000
  delay       : 907
  avail       : 1141
  avail_max   : 2043

The next time the audio write is called the state is checked and found
to be in XRUN with 225 delay in the buffer:??? (And yet I've seen other
writes find the device still running with alot less delay in the buffer??):

[ +936 auddev_alsa.c] In SND_PCM_STATE_XRUN  - preparing audio
[pid/9901 +945 auddev_alsa.c] Frames avail to be written=2048, time
diff=43182, Trying to write 640 frames, Curr delay 0
  state       : XRUN
  trigger_time: 1194622843.886113000
  tstamp      : 0.000000
  delay       : 225
  avail       : 1823
  avail_max   : 2049
[pid/9901 +954 auddev_alsa.c] Wrote 1280 bytes, frames: 640
  state       : RUNNING
  trigger_time: 1194622844.142516000
  tstamp      : 0.000000
  delay       : 637
  avail       : 1411
  avail_max   : 1708

Currently I'm stumped at to solve these problems.... And basically ALSA
sound quality as worse than the OSS driver for RAT as a result.

Any suggestions are to how improve or sort these problems is welcome.

Thanks,

Piers O'Hanlon.
University College London

===snd_pcm_dump_setup:===============
  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 1
  rate         : 16000
  exact rate   : 16000 (16000/1)
  msbits       : 16
  buffer_size  : 2048
  period_size  : 341
  period_time  : 21333
  tick_time    : 0
  tstamp_mode  : NONE
  period_step  : 1
  sleep_min    : 0
  avail_min    : 341
  xfer_align   : 1
  start_threshold  : 341
  stop_threshold   : 2048
  silence_threshold: 0
  silence_size : 0
  boundary     : 536870912

Re: Getting XRUN after writei in RUNNING state?

[Jaroslav Kysela]

On Fri, 9 Nov 2007, Piers O'Hanlon wrote:

> ===snd_pcm_dump_setup:===============
>   stream       : PLAYBACK
>   access       : RW_INTERLEAVED
>   format       : S16_LE
>   subformat    : STD
>   channels     : 1
>   rate         : 16000
>   exact rate   : 16000 (16000/1)
>   msbits       : 16
>   buffer_size  : 2048
>   period_size  : 341
>   period_time  : 21333
>   tick_time    : 0
>   tstamp_mode  : NONE
>   period_step  : 1
>   sleep_min    : 0
>   avail_min    : 341
>   xfer_align   : 1
>   start_threshold  : 341
>   stop_threshold   : 2048
>   silence_threshold: 0
>   silence_size : 0
>   boundary     : 536870912

Could you do whole dump (snd_pcm_dump()) to see all plugins in chain?
I judge from period_size that we have another problem with rate plugin.
It would be better to do rate resampling in RAT.

						Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project

Re: Getting XRUN after writei in RUNNING state?

[Piers O'Hanlon]

Hi,

Thanks for getting back me.

Jaroslav Kysela wrote:
> On Fri, 9 Nov 2007, Piers O'Hanlon wrote:
> ....
>
> Could you do whole dump (snd_pcm_dump()) to see all plugins in chain?
> I judge from period_size that we have another problem with rate plugin.
> It would be better to do rate resampling in RAT.
>   
I set the period size to the match the closest to the expected minimum
audio packet size (20ms - 320 bytes in our case) - I wasn't sure the
best choice for all parameters. I initially set the buffer size to
approx 3 packets - though I tried increasing to twice that. It just
wasn't clear which parameters were causing it to go into XRUN (I also
set the stop threshold to maximum to make sure it was the stop
threshold  - though I guess it it overrun the buffer size we'll get
audio from the beginning of the ring buffer anyway wthat wouldn't sound
too good)

(snd_pcm_dump()) is below:

 
Plug PCM: Rate conversion PCM (48000, sformat=S16_LE)
Its setup is:
  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 1
  rate         : 16000
  exact rate   : 16000 (16000/1)
  msbits       : 16
  buffer_size  : 2048
  period_size  : 341
  period_time  : 21333
  tick_time    : 0
  tstamp_mode  : NONE
  period_step  : 1
  sleep_min    : 0
  avail_min    : 341
  xfer_align   : 1
  start_threshold  : 341
  stop_threshold   : 2048
  silence_threshold: 0
  silence_size : 0
  boundary     : 536870912
Slave: Route conversion PCM (sformat=S16_LE)
  Transformation table:
    0 <- 0
    1 <- 0
Its setup is:
  stream       : PLAYBACK
  access       : MMAP_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 1
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 16
  buffer_size  : 6144
  period_size  : 1024
  period_time  : 21333
  tick_time    : 0
  tstamp_mode  : NONE
  period_step  : 1
  sleep_min    : 0
  avail_min    : 1024
  xfer_align   : 3
  start_threshold  : 1024
  stop_threshold   : 6144
  silence_threshold: 0
  silence_size : 0
  boundary     : 1610612736
Slave: Direct Stream Mixing PCM
Its setup is:
  stream       : PLAYBACK
  access       : MMAP_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 2
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 16
  buffer_size  : 6144
  period_size  : 1024
  period_time  : 21333
  tick_time    : 0
  tstamp_mode  : NONE
  period_step  : 1
  sleep_min    : 0
  avail_min    : 1024
  xfer_align   : 3
  start_threshold  : 1024
  stop_threshold   : 6144
  silence_threshold: 0
  silence_size : 0
  boundary     : 1610612736
Hardware PCM card 0 'AMD AMD8111' device 0 subdevice 0
Its setup is:
  stream       : PLAYBACK
  access       : MMAP_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 2
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 16
  buffer_size  : 16384
  period_size  : 1024
  period_time  : 21333
  tick_time    : 4000
  tstamp_mode  : NONE
  period_step  : 1
  sleep_min    : 0
  avail_min    : 1024
  xfer_align   : 1024
  start_threshold  : 1
  stop_threshold   : 1073741824
  silence_threshold: 0
  silence_size : 1073741824
  boundary     : 1073741824

> 						Jaroslav
>
> -----
> Jaroslav Kysela <perex@perex.cz>
> Linux Kernel Sound Maintainer
> ALSA Project
>   

Re: Getting XRUN after writei in RUNNING state?

[Piers O'Hanlon]

Hi Jaroslav,

Just to let you know I'm running this on Ubuntu 7.10
(alsa-lib-1.0.14), though I've been seeing this underrun problem for a
while on a few systems (Ubuntu 7.04/6.10, and Gentoo 2006.1). It
hasn't been clear to me what the key parameters are that control
underrun behaviour. (It would be great if someone wrote a
comprehensive book/article on ALSA....)

BTW you mentioned doing the rate resampling in RAT - which it can do -
how does one discover if rate conversion is occurring in ALSA and
obtain that 'base' rate? (Though I has assumed that ALSA would do the
better job of rate resampling if it was necessary...).

Thanks,

Piers.

On 09/11/2007, Jaroslav Kysela <perex@perex.cz> wrote:
> On Fri, 9 Nov 2007, Piers O'Hanlon wrote:
>
> > ===snd_pcm_dump_setup:===============
> >   stream       : PLAYBACK
> >   access       : RW_INTERLEAVED
> >   format       : S16_LE
> >   subformat    : STD
> >   channels     : 1
> >   rate         : 16000
> >   exact rate   : 16000 (16000/1)
> >   msbits       : 16
> >   buffer_size  : 2048
> >   period_size  : 341
> >   period_time  : 21333
> >   tick_time    : 0
> >   tstamp_mode  : NONE
> >   period_step  : 1
> >   sleep_min    : 0
> >   avail_min    : 341
> >   xfer_align   : 1
> >   start_threshold  : 341
> >   stop_threshold   : 2048
> >   silence_threshold: 0
> >   silence_size : 0
> >   boundary     : 536870912
>
> Could you do whole dump (snd_pcm_dump()) to see all plugins in chain?
> I judge from period_size that we have another problem with rate plugin.
> It would be better to do rate resampling in RAT.
>
>                                                 Jaroslav
>
> -----
> Jaroslav Kysela <perex@perex.cz>
> Linux Kernel Sound Maintainer
> ALSA Project
>