Re: [ecasound] obviously wrong ALSA underruns reported by ecasound-2.6.0

--- On Wed, 11/25/09, Kai Vehmanen <kvehmanen@email-addr-hidden> wrote:

> From: Kai Vehmanen <kvehmanen@email-addr-hidden>
> Subject: Re: [ecasound] obviously wrong ALSA underruns reported by ecasound-2.6.0
> To: "Sergei Steshenko" <sergstesh@email-addr-hidden>
> Cc: ecasound-list@email-addr-hidden
> Date: Wednesday, November 25, 2009, 9:41 AM
> Hi,
>
> On Mon, 23 Nov 2009, Sergei Steshenko wrote:
>
> > " WARNING: ALSA playback underrun, glitches in audio
> playback possible! Break was at least 566281884.09 ms long.
> "
> [...]
> > In reality the drop was like 1 second, maybe less.
> [...]
> > Is it a known issue ?
> >
> > Which of the two - ecasound or ALSA - reports
> underruns ?
>
> ok, tis is quite interesting? The warning is printed by
> ecasound, but the code has remained the same for who now how
> many years, and is virtually identical to the warning
> printed by the most recent aplay (of alsa-utils). Only thing
> that's different that ecasound does not use the monotonic
> timestamps even if they are available (reason: these are a
> later addition and were not available when ecasound's ALSA
> code was written).
>
> What version of alsa-lib and kernel (cat
> /proc/asound/version for the latter)
> do you have...? Also what soundcard/chip do you have (cat
> /proc/asound/cards)...?
>
> > I'd say, I've never seen a reasonable number since
> upgrade to both
> > SUSE-11.1 (i.e. newer ALSA) and ecasound-2.6.0 - from
> ecasound-2.5.2
> >
> > Both versions of ecasound are self-built using the
> same tool of mine.
>
> So I'm 99+% sure it's caused by the ALSA upgrade (the xrun
> reporting code is exactly the same in 2.5.2 as in 2.6.0).
>
> Now the actual bug might still be in ecasound (and possibly
> in aplay as well), but it's just been hidden with older ALSA
> versions. Hmm, I wonder how I could reproduce this myself...
> :P
>
> > WARNING: ALSA playback underrun, glitches in audio
> playback possible! Break was at least 566281807.81 ms long.
> > WARNING: ALSA playback underrun, glitches in audio
> playback possible! Break was at least 566281802.92 ms long.
>
> Btw, in any case the XRUN is real in these cases (this
> warning is only printed when the stream goes to XRUN state
> and the length estimation is done as a separate step). I.e.
> the break length is not used to decide whether there was a
> XRUN or not... (this would be a fairly bad bug).
>

'uname -a' output:

Linux amdam2 2.6.27.37-0.1-default #1 SMP 2009-10-15 14:56:58 +0200 i686 athlon i386 GNU/Linux

'cat /proc/asound/version' output:

"
Advanced Linux Sound Architecture Driver Version 1.0.17
",

but (!) at the same time:

"
rpm -q alsa
alsa-1.0.18-8.12.1
"

Sound chip:

"
Card: HDA NVidia
Chip: Realtek ALC883
".

I don't know how to answer regarding ALSA library, for example, ALSA
plugins are 1.0.18-6.12, but "Samplerate Plug-In for the ALSA Library" is
1.0.14-41. alsa-utils is 1.0.18-6.4.

It's SUSE package manager which decided to install these versions.

I know XRUNs are real; overall sound feels better - it appears now out of
the box audio applications have realtime priority (or is it just a bigger
buffer ?) - pretty heavy applications which used to skip sometimes
because of file access in parallel with file access of other applications
seem to work much smoother now.

The reported XRUNs were observed during Internet MP3 stream playback, and
as such do not surprise me, but I payed attention to the numbers.

Thanks,
  Sergei.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Ecasound-list mailing list
Ecasound-list@email-addr-hidden
https://lists.sourceforge.net/lists/listinfo/ecasound-list
Received on Thu Nov 26 00:15:02 2009