You are not logged in.
Pages: 1
Topic closed
Hello, I use ALSA together with PULSEAUDIO. And every time I listen to any audio, mainly internet radio streams (using vlc, or lastfm in Firefox), I get this annoying distortion, sound clipping. I can't even describe it, imagine listening to a song when every second or so there is a small crackle/distortion. This is starting to get really anoying. Surprising this crippling doesn't affect Sonata, and sometimes vlc sounds good too. Volume isn't 100% anywhere, no distortion from that.
Also to mention, I 2 sound-cards. The main is for a 5.1 sound-system which I can't configure quite well, because when I set default_channels in daemon.conf for pulse, audio gets really weird. The other one I do not use that often. This isn't the main problem, though. I'm concerned about the crippled sound. I have noticed this only on Arch...
I have tried OSS, but I found it somehow even worse, because I instantly got audio problems system wide - bigger distortion to everything.
Does anyone has had similar problems ? Or maybe you can post your ideal audio configuration/setup ?
Arch64 | some tiling wm
Offline
you are not alone... best you can do is try and change a few settings in /etc/pulse/daemon.conf
I changed these values to the following and it seemed to help some what... although it is still scratchy at the beginning of some VLC videos...
default-fragments = 5
default-fragment-size-msec = 25
high-priority = yes
nice-level = -11
Also I set the following to the best (also highest cpu)...
resample-method = src-sinc-best-quality
from best to worst the options are:
src-sinc-best-quality, src-sinc-medium-quality, src-sinc-fastest, speex-float-{10-0}, speex-fixed-{10-0}, ffmpeg, src-zero-order-hold, src-linear, trivial
Offline
Thanks for the reply. I fiddled with the dameon.conf, but no success, still pretty much the same, or even worse... I'll fiddle with the conf some.
Arch64 | some tiling wm
Offline
What version of PulseAudio are you using? It seemed to me to be worse with 0.9.14 then the current git/testing preview or 0.9.15... however the distortion is still there but usally just in the first few seconds of the song/video then seems to stop.
Offline
I found Lennart's post on this issue.... re-compiling my kernel to 1000mhz and with pre-emption enabled fixed my issues.
[pulseaudio-discuss] Distribution kernels and glitch-free (Packagers, read this!)
Lennart Poettering
Sun, 22 Feb 2009 11:37:31 -0800Heya!
As one result of the alsa-time-test testing (see that last mail of
mine regarding broken sound drivers) input I got from folks, I learned
how very different the different distribution kernels actually
behave. They are much more different than i actually assumed.Apparently OpenSUSE ships a kernel (2.6.27.7-9-pae) that causes
scheduling latencies of > 210ms. That is a lot. That is really really
really a lot. Other non-Fedora distributions apparently do something similar.The parameters in the glitch-free logic are tuned for Fedora-kernels
that easily give latencies of 5ms or so.ALSA artificially limits the overall buffer size to 64k (i.e. 371ms on
44100hz/2ch/s16le). That this size is not that much when speaking of
scheduling latencies of 210ms should be obvious.Now, the glitch-free mode in PA is a major departure from the
traditional playback mode. In traditional playback mode the sound card
buffer is filled as soon as at least one 'fragment' of it ran
empty. Usually 4 fragments or so are used, i.e. the fill level will
oscillate between 'full' and 'full minus one fragment size minus the
scheduling latency'. If we have a buffer of 371ms we have a fragment
size of 91ms. With a kernel like that OpenSUSE kernel hence the fill
level oscillates between 371ms and 70ms. Which of course is usually
good enough to not get a drop out. Should a drop out happen nonethless
we continue as if nothing happened given that fragment settings cannot
be reconfigured during runtime.Now, let's have a look what this means for glitch-free mode. In g-f
mode we disable sound card interrupts (and get rid of 'fragments'
entirely) as far as possible to minimize power consumption. We
schedule audio via system timers instead of the sound card's fragment
logic. Instead of already filling up after a single fragment was
played we delay the fill up until only 10 ms are still left in the
buffer (in PA 0.9.14 that is, i increased the default to 20ms now on
.15). i.e. with a Fedora scheduling latency of 5ms the buffer fill
level will hence oscillate between 371ms and 5ms. Still good enough to
not get into drop outs. If a drop out happens nonethelless we will
double the 10 ms to 20ms and go on. If that still turns out to not be
enough we double again, and so on. If this logic with these parameters
is run on an OpenSuse kernel, drop-outs will necessarily happen right
away. Because 10ms minus the sched latency of 210ms equals
FAILURE. And doubling the wakeup time again and again will require
quite a number of iterations, i.e. more than just a few underruns at
the beginning. Also the doubling will quickly come near to the full
buffer size of 371ms causing a lot of CPU to be eaten, since we will
wake up very very often.So, what do we read from this?
0) Fedora is awesome, other distributions suck ;-)
1) For ***** sakes: get your bloody kernels fixed. Enable preempt, set
HZ to 1000. Get rid of low-quality drivers that block the
CPU. Latencies of 210ms is *REALLY NOT NECESSARY*.2) If you want to stick with your crap kernel, then either disable g-f
entirely or adjust the #defines at the top of
src/modules/alsa-sink.c and src/modules/alsa-source.c.Thank you very much,
Lennart
Offline
I had the same problem
Afther changing default-sample-rate from 44100 to 48000 in /etc/pulse/deamon.conf found in http://wiki.archlinux.org/index.php/Pul … leshooting, problem solved.
Last edited by Aas (2010-07-17 21:10:34)
Offline
I had the same problem
Afther changing default-sample-rate from 44100 to 48000 in /etc/pulse/deamon.conf found in http://wiki.archlinux.org/index.php/Pul … leshooting, problem solved.
Sweet. I'm glad that you got this solved.
And, this is a wrap.
Offline
Pages: 1
Topic closed