Alsa sound *jumpy*: alsa-space: xrun of at least 11.449 msecs. resetting stream

qwijibow · 04-07-2005, 11:29 AM

first, the details...

CPU: AMD_64 Athlon 3400+
Kernel Version: 2.6.11-gentoo-r3
Distro: 64Bit Gentoo.
Alsa Driver: CONFIG_SND_INTEL8X0=y (intel 8x0)
Sound Hardware: Nvidia Nforce 3
Alsa-lib version: 1.0.8

My sound used to work fine, but then my speakers died, and i didnt replace them for a few weeks, so i dont know xactly caused the malfunction, (i just notivced it today with my new speakers) but i have done a complete system uptate in the speaker-less time.

The problem is a very strange one.

I did not compile OSS emulation, only ALSA interface.
when mplayer, or any other program uses ALSA directly, the sound is very jumpy, and the folloing code is output to the console...

Code:

alsa-space: xrun of at least 0.946 msecs. resetting stream
alsa-space: xrun of at least 11.724 msecs. resetting stream
alsa-space: xrun of at least 11.546 msecs. resetting stream
alsa-space: xrun of at least 11.449 msecs. resetting stream
alsa-space: xrun of at least 11.520 msecs. resetting stream
alsa-space: xrun of at least 2.470 msecs. resetting stream

one line is output for every audio *jump*, and it jumps approxamatly twice a seccond.

However... this is where it gets strange..... If i play inderctly, through the Arts sound server (which uses alsa) then the sound is perfect !

i have tried reinstalling alsa-libs and alsa-utils. nether made any difference.

Any idea's anyone ???

nielchiano · 04-19-2005, 12:32 PM

sorry, no ideas; but just a dumb "me-too" reply

I have the exact same symptoms. I can add that playing through OSS-emulation also solves the problem with me

foo_bar_foo · 04-19-2005, 03:04 PM

must or might be something wrong with the buffer settings try something like this and adjust it and see if you can make it better
in ~/.asoundrc

Code:

pcm.dsp {
    type plug
    slave.pcm "dmixer"
}

pcm.!default {
    type plug
    slave.pcm "dmixer"
   
}

ctl.!default {
	type hw           
	card 0
        }

pcm.dmixer  {
	type dmix
	ipc_key 1024
	slave {
	    pcm "hw:0,0"
	    period_time 0
         #   period_time 84000 
	 #   period_size 2048
         #   buffer_time 340000
	 #   buffer_size 16384
            rate 44100
	 #   rate 48000
            period_size 1024
        ##    buffer_size 4096
            buffer_size 8192
	}
	bindings {
	    0 0
	    1 1
	}
    }
 
    ctl.dmixer {
	type hw
	card 0
    }

i just left the variouse setting i was playing with in there as examples -- just comment or uncomment to play with the values

nielchiano · 04-21-2005, 12:15 PM

I've been googleing for it, but didn't find it (yet).
What do these settings change? buffer_size, period_size, period_time??

foo_bar_foo · 04-21-2005, 01:24 PM

i'm not that up on the details either

buffer size is the buffer size in microseconds not in physical size (64 frames per interrupt is the lowest currently possible in any PC audio hardware) so you should increase the frames (buffer size) in multiples of 2 starting at 64
generally low latency systems use a period size of 2
(i don't fully understand pariod size)
alsa allows other values and sometimes i see lots of people on the internet using 0 but that doesn't seem quite right.
Period Time is the outflow speed (size ??) and i think this should be about half of the total buffer size
buffer_size 1026
period_size 512
period_time 2
might be a good place to start to see if it will run like that ????
buffer_size 2052
period_size 1026
period_time 2
seems to work a little smoother here

the distance between writes and reads is what is refered to as audio latency and might need to be a certain size so software doesn't get overrunn ??? the whole thing is a bit of a mystery and has something to do with what the cpu and memory is doing as well
the more direct it is (low latency) the more easily it gets interupted

alsa buffer is a "ring" buffer -- that is, a FIFO buffer (fist in first out)
in other words it reads and writes from front to back

with a cycle like that -- it is possible for the buffer to get all full so the reads are in the way (slower) than the writes
and it's also possible for the buffer to get all empty where the reads are faster than the writes

both situations also cause interuption in the flow

lukesky · 04-03-2006, 10:58 AM

Thank you very much. I had exacltly the same problem with alsa and I solved it using the configuration reported above for .asoundrc

Quote:

Originally Posted by foo_bar_foo

must or might be something wrong with the buffer settings try something like this and adjust it and see if you can make it better
in ~/.asoundrc

(...)

praetis · 04-22-2006, 07:35 PM

I was having the same problem and creating the .asoundrc file as stated above fixed it for me as well.