Bug 470568

What audio hw/driver are you using?

lspci shows
00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia

and I'm using 
options snd-hda-intel index=0 model=toshiba position_fix=1

in /etc/modprobe.d/modprobe.conf.dist according to ubuntu guide for the tx2500. The sound plays smoothly in Gnome, although I haven't try playing something from Amarok in Gnome. I'll try that later today and I'll post the results.

xine-0.99.5-5.fc10.i386.rpm
xine-lib-1.1.15-3.fc10.i386.rpm
with 
xine-lib-pulseaudio.i386 1.1.15-3.fc10 

segfaults :
kernel: xine[13879]: segfault at 0 ip 014ef4dc sp b52a9e30 error 4 in libpulse.so.0.7.0[1493000+6e000]

if remove xine-lib-pulseaudio.i386, xine works without problems. 

Of course xine also works with xine -A alsa even with xine-lib-pulseaudio installed

Separate issue.

xine (not in fedora mind you), is known to segfault when used with xine-lib-pulseaudio, that's arguably a xine bug (see https://bugzilla.rpmfusion.org/show_bug.cgi?id=125 )

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

I'm experiencing this bug in F10 when using pulseaudio, switching to another device in system-settings removes the problem.
I get the "choppy" sound at startup and when starting audio playback in amarok 2, also by resuming from pause, for the first couple of seconds, then it continues well.


rpm -qa | grep pulse
kde-settings-pulseaudio-4.1-4.20081031svn.fc10.noarch
pulseaudio-0.9.13-6.fc10.i386
pulseaudio-utils-0.9.13-6.fc10.i386
pulseaudio-module-x11-0.9.13-6.fc10.i386
pulseaudio-libs-0.9.13-6.fc10.i386
pulseaudio-esound-compat-0.9.13-6.fc10.i386
pulseaudio-core-libs-0.9.13-6.fc10.i386
alsa-plugins-pulseaudio-1.0.18-1.rc3.fc10.i386
pulseaudio-module-gconf-0.9.13-6.fc10.i386
plymouth-plugin-pulser-0.6.0-0.2008.11.17.3.fc10.i386
pulseaudio-module-bluetooth-0.9.13-6.fc10.i386
pulseaudio-libs-glib2-0.9.13-6.fc10.i386
xine-lib-pulseaudio-1.1.15-3.fc10.i386

lspci|grep Audio
00:05.0 Multimedia audio controller: nVidia Corporation nForce Audio Processing Unit (rev a2)
00:06.0 Multimedia audio controller: nVidia Corporation nForce2 AC97 Audio Controler (MCP) (rev a1) <-- I believe pulseaudio is using this one

I can confirm comment #6.
my setup: F10, KDE 4.1.3
using amarok 2.0 final (bug existed before as well)

$ rpm -qa|grep pulse
pulseaudio-utils-0.9.13-6.fc10.i386
pulseaudio-libs-0.9.13-6.fc10.i386
pulseaudio-core-libs-0.9.13-6.fc10.i386
alsa-plugins-pulseaudio-1.0.18-1.rc3.fc10.i386
pulseaudio-libs-glib2-0.9.13-6.fc10.i386
kde-settings-pulseaudio-4.1-4.20081031svn.fc10.noarch
pulseaudio-0.9.13-6.fc10.i386
pulseaudio-module-x11-0.9.13-6.fc10.i386
xine-lib-pulseaudio-1.1.15-3.fc10.i386

$ lspci|grep Audio
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)

I stil confirm the comments #6 and #7.

My configuration is latest Fedora10 with KDE 4.1.3 and Amarok 2.0 final, but the bug existed since I installed Fedora 10.

I fixed it by setting in System Settings->Sound my alsa device "HDA Intel (Realtek ALC883) as first device, before "PulseAudio" which was the default. It looks like it is a xine+pulseAudio trouble, since the tooltip over "PulseAudio" says: "xine audio plugin using PulseAudio server".

$ rpm -qa|grep pulse
alsa-plugins-pulseaudio-1.0.18-1.rc3.fc10.x86_64
kde-settings-pulseaudio-4.1-4.20081031svn.fc10.noarch
pulseaudio-0.9.13-6.fc10.x86_64
pulseaudio-libs-glib2-0.9.13-6.fc10.x86_64
pulseaudio-utils-0.9.13-6.fc10.x86_64
pulseaudio-esound-compat-0.9.13-6.fc10.x86_64
pulseaudio-libs-0.9.13-6.fc10.x86_64
pulseaudio-module-gconf-0.9.13-6.fc10.x86_64
pulseaudio-core-libs-0.9.13-6.fc10.x86_64
pulseaudio-module-x11-0.9.13-6.fc10.x86_64
xine-lib-pulseaudio-1.1.15-3.fc10.x86_64

$ lspci | grep Audio
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 02)

rpm -e xine-lib-pulseaudio alsa-plugins-pulseaudio kde-settings-pulseaudio pulseaudio-esound-compat pulseaudio-module-x11 etc solve my problem

Yeah but that means getting rid of pulseaudio, which is not what we want, nor why is this bug reported here. I confirm this behavior is still present in F10 64bit, Amarok 2.0 final and KDE 4.2 Beta 2 (4.1.85) from kde-redhat repo.

rpm -qa | grep pulse
alsa-plugins-pulseaudio-1.0.18-1.rc3.fc10.x86_64
pulseaudio-module-x11-0.9.13-6.fc10.x86_64
pulseaudio-0.9.13-6.fc10.x86_64
xine-lib-pulseaudio-1.1.15-3.fc10.x86_64
pulseaudio-core-libs-0.9.13-6.fc10.x86_64
pulseaudio-module-gconf-0.9.13-6.fc10.x86_64
pulseaudio-libs-0.9.13-6.fc10.i386
pulseaudio-libs-glib2-0.9.13-6.fc10.x86_64
kde-settings-pulseaudio-4.1-4.20081031svn.fc10.noarch
pulseaudio-esound-compat-0.9.13-6.fc10.x86_64
pulseaudio-libs-0.9.13-6.fc10.x86_64
pulseaudio-utils-0.9.13-6.fc10.x86_64

lspci | grep Audio
00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia

Adjusting summary, since everyone here so far seems to be using snd-hda-intel driver.

I'm not sure about the relation with snd-hda-intel: my brother has a Creative Sound Blaster and is experiencing the same problem. If I use GNOME with my Intel card and set pulseaudio as sound server it works perfectly. If I try to uninstall xine-lib-pulseaudio this removes also alsa-plugins-pulseaudio and kde-settings-pulseaudio. Then under gnome pulseaudio continues to work, and under KDE everything mutes. My idea is that is someting related to xine-lib-pulseaudio.

If you search bugzilla, you'll find creative has it's own issues (and separate bugs already), but let's keep *this* one about intel.

Hi, mine is intel 

        Kernel modules: snd-intel8x0
        Kernel modules: snd-intel8x0m

mixer says that is : 
Intel ICH6 

My ALSA information is located at: 
http://www.alsa-project.org/db/?f=a4255ff2e47050d21565a422a16073d38e52d67f

BTW : what better features pulseaudio have ?

> BTW : what better features pulseaudio have ?

please, bugzilla is for *bugs*, not discussion and is offtopic here.

how can I help to trace this bug? Is there any hint where the problem is? Can I help with any further information? I'd really like to fix this, it's quite annoying for me as I'm always listening to music...

Maybe it's something related to the bug reported here:
http://www.pulseaudio.org/ticket/420

I found those messages in my /var/log/messages reported by pulseaudio:

Dec 27 09:03:57 quad pulseaudio[3800]: main.c: Called SUID root and real-time/high-priority scheduling was requested in the configuration. However, we lack the necessary privileges:
Dec 27 09:03:57 quad pulseaudio[3800]: main.c: We are not in group 'pulse-rt' and PolicyKit refuse to grant us privileges. Dropping SUID again.
Dec 27 09:03:57 quad pulseaudio[3800]: main.c: For enabling real-time scheduling please acquire the appropriate PolicyKit privileges, or become a member of 'pulse-rt', or increase the RLIMIT_NICE/RLIMIT_RTPRIO resource limits for this user.
Dec 27 09:03:57 quad pulseaudio[3800]: main.c: High-priority scheduling enabled in configuration but not allowed by policy.
Dec 27 09:03:57 quad pulseaudio[3800]: core-util.c: setpriority(): Permission denied
Dec 27 09:03:57 quad pulseaudio[3794]: alsa-util.c: Device hw:0 doesn't support 44100 Hz, changed to 16000 Hz.
Dec 27 09:03:57 quad pulseaudio[3794]: alsa-util.c: Device hw:0 doesn't support 2 channels, changed to 1.
Dec 27 09:03:58 quad pulseaudio[3819]: pid.c: Daemon already running.
Dec 27 09:17:01 quad pulseaudio[3794]: module-alsa-sink.c: Increasing wakeup watermark
 to 40,00 ms

The last messages seems to appear the first time a sound is played.

I've checked up the /var/log/messages too and I have these:

Dec 27 11:56:02 localhost pulseaudio[3099]: alsa-util.c: snd_pcm_avail_update() returned a value that is exceptionally large: 1509236 bytes (8555 ms) Most likely this is an ALSA driver bug. Please report this issue to the PulseAudio developers.
Dec 27 11:56:02 localhost pulseaudio[3099]: module-alsa-sink.c: Increasing wakeup watermark to 80,00 ms
Dec 27 11:56:02 localhost pulseaudio[3099]: module-alsa-sink.c: snd_pcm_rewind() failed: Deskriptor souboru se nachází v chybném stavu
Dec 27 11:56:14 localhost pulseaudio[3099]: cpulimit.c: Recevied request to terminate due to CPU overload.
Dec 27 15:30:29 localhost pulseaudio[4278]: module-alsa-sink.c: Increasing wakeup watermark to 40,00 ms
Dec 27 22:23:14 localhost pulseaudio[3180]: pid.c: Daemon already running.
Dec 27 22:40:48 localhost pulseaudio[3168]: module-alsa-sink.c: Increasing wakeup watermark to 40,00 ms

Sound has been played but no simillar lines appears...

I confirm this as well.  Although, my sound card is ATI, not intel.

$ lspci |grep -i audio
00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia

Fedora 10
KDE4.1.3

This appears to be a bug with KDE sound system more than with Fedora (at least for me).  When I configure KDE notifications to use an external player such as sox (/usr/bin/play) all works fine.

Nod, xine-lib-pulseaudio (which is what the default phonon-backend-xine uses) likely does at least play some part here.

I fixed it perfectly by installing package phonon-backend-gstreamer and setting it as default backend in "System Settings->Sound->Backend". This fixes the problem without disabling pulseaudio, so sound multiplexing now works (while if you set the ALSA device as default, you will be able to play only one sound at a time; e.g.: no notifications while Amarok is playing). So, this bug is someway related to xine-lib-pulseaudio.

s/fixed/worked-around/, and by varying definitions of "perfect".  There's good reason we didn't default to using phonon-backend-gstreamer  (it has/had other issues, which made it unsuitable).

I just tried the gstreamer thing, and -- while the stuttering at the start of sounds didn't happen any more -- the sound was full of cracks and pops, especially under load. Also, I may have been missing a plugin or something, but using gstreamer, amarok refused to play any of my .flac files.

(In reply to comment #23)
> s/fixed/worked-around/, and by varying definitions of "perfect".  There's good
> reason we didn't default to using phonon-backend-gstreamer  (it has/had other
> issues, which made it unsuitable).

Sounds like an angel's sex discussion: using firefox instead of Konqueror is not a "fix" of a Konqueror's bug, of course :-) I was just saying that if gstreamer has a completely different behaviour (which is perfect, maybe only on my machine) this maybe means that choppy sound experienced using xine is somewhat related to xine. I just thought this could be a useful information. That's all.

I have this problem too (using intel hda, too). I already did some debugging and
it seems that xine uses two threads for handling audio: one for decoding the
audio data and one to push the decoded data to the sound driver. Both threads
start nearly at the same time and when the decoder thread is too slow to provide
enough data then xine inserts 0-frames which results in this heavy skipping in
the first seconds until enough data is available. When xine's debugging facility
is enabled then you'll even see the related messages. I used totem configured
with xine backend for this:

---------------
$ totem --debug <audio file (mp3 in my case)>
...
output sample rate 44100
audio jump, diff=-7
audio_out: inserting 10634 0-frames to fill a gap of 21736 pts
audio_out: inserting 10919 0-frames to fill a gap of 22318 pts
audio_out: inserting 8533 0-frames to fill a gap of 17442 pts
audio_out: inserting 8552 0-frames to fill a gap of 17480 pts
audio_out: inserting 7613 0-frames to fill a gap of 15562 pts
...
---------------

So why does this happen only with the "glitch-free" pulseaudio server? Actually
I do not really know this but I suspect that the pulseaudio client code now has
different cpu usage characteristics that changes scheduling behavior. Maybe
even the pulse audio backend in xine is just buggy...

Currently I have not too much time to do more debugging. But it would be nice
if someone could debug this further.

Thanks!

Created attachment 328634 [details]
Hack to fix the problem (for audio only)

I have some more details now:

It seems that the audio stream latency reported by pulseaudio is very
unstable in the first seconds after start playing (increases in large
steps) and will become more stable later. The audio video synchronization
code tries to cope with that but if the delay increased by a large amount
in a short time xine will compensate with empty frames (skips). When
pulseaudio is running without the "glitch-free" stuff the latency is more
stable and xine is happy with that.

I have created a little hack that avoids the skips in the case of
audio-only material. The hack just avoids any compensation for sound
card drift if we have no video stream. I'm not sure if there are cases
where this does not work but at least for me this works quite well.

Created attachment 328639 [details]
Hack to fix the problem (for audio only) (revised)

Last patch contained a crasher... sorry.

This solved the problem for me too....thanks.

Lennart, does the xine-lib patch look sane to you (as a short-term workaround)?

poked xine-lib upstream for comment too:
http://sourceforge.net/mailarchive/forum.php?thread_name=gl7qsp%24rc1%241%40ger.gmane.org&forum_name=xine-devel

I also confirm this issue

Fedora 10, KDE 4.1.3

lspci | grep -i audio
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02)

rpm -qa | grep pulse
pulseaudio-libs-0.9.13-6.fc10.i386
pulseaudio-core-libs-0.9.13-6.fc10.i386
xine-lib-pulseaudio-1.1.16-1.fc10.i386
kde-settings-pulseaudio-4.1-4.20081031svn.fc10.noarch
pulseaudio-0.9.13-6.fc10.i386
alsa-plugins-pulseaudio-1.0.18-2.fc10.i386
pulseaudio-module-x11-0.9.13-6.fc10.i386
pulseaudio-libs-glib2-0.9.13-6.fc10.i386
pulseaudio-utils-0.9.13-6.fc10.i386

The above patch also resolved the problem with xine-lib-1.1.16.1.

fwiw, patch included in xine-lib-1.1.16.1-1 build... Rawhide only for now... if no cries of anguish appear, F-9/F-10 updates will follow shortly.

xine-lib-1.1.16.1-1.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update xine-lib'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-0884

I still recive same results as first stated, choppy sound with what i assume is the new patched xine-lib, looking in /var/log/messages and seeing this, when i have tested sound in Firefox and Amarok.

Jan 24 08:44:18 localhost pulseaudio[3021]: module-alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write! Most likely this is an ALSA driver bug. Please report this issue to the PulseAudio developers.

rpm -qa | grep pulse
pulseaudio-libs-0.9.13-6.fc10.i386
pulseaudio-core-libs-0.9.13-6.fc10.i386
xine-lib-pulseaudio-1.1.16-1.fc10.i386
kde-settings-pulseaudio-4.1-4.20081031svn.fc10.noarch
pulseaudio-0.9.13-6.fc10.i386
alsa-plugins-pulseaudio-1.0.18-2.fc10.i386
pulseaudio-module-x11-0.9.13-6.fc10.i386
pulseaudio-libs-glib2-0.9.13-6.fc10.i386
pulseaudio-utils-0.9.13-6.fc10.i386

Im new to the whole "sound world" in Linux so let me know if i can provide any other useful debugging for faster resolving of the issue.

> xine-lib-pulseaudio-1.1.16-1.fc10.i386

You're using the older, unpatched version, please test the xine-lib-1.1.16.1-1 build mentioned in comment #35.

For me the sound works great now with the new fix, both in ff and in Amarok. No errormessages in syslog, nice work!!

Working as should, nicely done, thanks...

xine-lib-1.1.16.1-1.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

oops, inadvertantly had this auto-close, still waiting on feedback from pulseaudio folks per comment #30

adjusting summary per investigations from comment #27

(In reply to comment #42)
> adjusting summary per investigations from comment #27

Although this is the right name for this bug report, I would suggest to leave it more "human readable". If there will be someone with the same problems, I guess he won't search for "unstable audio stream latency", but rather for something like "kde and pulseaudio bad sound". This can lead to longer way to solve the problem, duplicated bug reports and so on.

Just my 2 cents...

I have xine-lib-1.1.16.2 and I still see this problem with xine/miro. (Have for all of Fedora 10) I use KDE as well, and am currently update to date with KDE 4.2.

Opening 2-5 seconds of video is choppy. I tried running "xine -f -A alsa" but I still see the problem. HOWEVER, I'm not sure that I'm bypassing pulseaudio. I kill it and confirm that it isn't running, but after I run xine, I see that it's in the process list again.

Also, (and maybe this is a separate bug) I've been seeing for awhile that audio seems to drift out of synch with xine. After the initial glitches it's usually (but not always) pretty close to in synch with the video, but after about 20-30mins it can be 3/4 of a second behind the video.

Creative XFi (using Creative's 1.00 driver compiled myself)
AMD Dual Core 64bit, 4gb Ram

To be clear, the patch included in fedora's xine-lib builds avoid the initial instability for audio-only streams.  Video requires synchronization.

Time should be perfectly stable during stream startup and afterwards with pulseaudio-0.9.15-9