Description of problem: I have installed the Fedora 10 Preview with both KDE and GNOME. The sound in gnome is just nice, but in KDE with phonon set to pulseaudio, the sound is...well...choppy. I've never heard the KDE startup sound completely, most of the times after the weird 2s playback it drops entirely. Same with amarok. The first 5 seconds are unlistenable, the audio breaks, pauses, jumps, cracks but then it plays ok. It's hard to describe...I may try to record it with some external device and post the result. Version-Release number of selected component (if applicable): 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 How reproducible: Always Steps to Reproduce: 1. Just play some audio with KDE 4.1.2 Actual results: Audio output is like on a very very slow machine with very small buffer, hard to describe (as I'm non-native english speaker) Expected results: Clear playback Additional info: I'm using the xine phonon implementation with PulseAudio as preferred output. There is also a PulseAudio Server, but it's no difference. But if I select just the soundcard as the preferred and not the PA, it plays just fine. Phonon is in version 4.2, Phonon-backend-xine is 4.1.2.
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