Bug 470568 - pulseaudio audio stream latency initially unstable
pulseaudio audio stream latency initially unstable
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: pulseaudio (Show other bugs)
10
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Lennart Poettering
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: 474752
  Show dependency treegraph
 
Reported: 2008-11-07 13:14 EST by Martin Klapetek
Modified: 2009-04-10 10:51 EDT (History)
18 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-10 10:51:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Hack to fix the problem (for audio only) (872 bytes, patch)
2009-01-10 14:15 EST, Ronald Wahl
no flags Details | Diff
Hack to fix the problem (for audio only) (revised) (935 bytes, patch)
2009-01-10 16:06 EST, Ronald Wahl
no flags Details | Diff

  None (edit)
Description Martin Klapetek 2008-11-07 13:14:53 EST
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.
Comment 1 Rex Dieter 2008-11-11 10:56:10 EST
What audio hw/driver are you using?
Comment 2 Martin Klapetek 2008-11-11 11:18:33 EST
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.
Comment 3 Sergio Monteiro Basto 2008-11-18 10:21:49 EST
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
Comment 4 Rex Dieter 2008-11-18 10:32:59 EST
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 )
Comment 5 Bug Zapper 2008-11-26 00:00:16 EST
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
Comment 6 Attilio 2008-12-02 10:13:18 EST
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
Comment 7 Thomas R. 2008-12-14 05:22:41 EST
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)
Comment 8 Davide Rondini 2008-12-18 04:09:07 EST
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)
Comment 9 Sergio Monteiro Basto 2008-12-18 11:26:26 EST
rpm -e xine-lib-pulseaudio alsa-plugins-pulseaudio kde-settings-pulseaudio pulseaudio-esound-compat pulseaudio-module-x11 etc solve my problem
Comment 10 Martin Klapetek 2008-12-18 12:15:07 EST
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
Comment 11 Rex Dieter 2008-12-18 12:23:10 EST
Adjusting summary, since everyone here so far seems to be using snd-hda-intel driver.
Comment 12 Davide Rondini 2008-12-19 02:46:51 EST
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.
Comment 13 Rex Dieter 2008-12-19 09:09:03 EST
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.
Comment 14 Sergio Monteiro Basto 2008-12-19 11:07:22 EST
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 ?
Comment 15 Rex Dieter 2008-12-19 11:40:20 EST
> BTW : what better features pulseaudio have ?

please, bugzilla is for *bugs*, not discussion and is offtopic here.
Comment 16 Thomas R. 2008-12-19 12:21:33 EST
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...
Comment 17 Davide Rondini 2008-12-27 04:09:31 EST
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.
Comment 18 Martin Klapetek 2008-12-28 12:29:46 EST
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...
Comment 19 Fred Wells 2008-12-30 09:39:12 EST
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
Comment 20 Fred Wells 2009-01-03 17:21:30 EST
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.
Comment 21 Rex Dieter 2009-01-03 22:06:33 EST
Nod, xine-lib-pulseaudio (which is what the default phonon-backend-xine uses) likely does at least play some part here.
Comment 22 Davide Rondini 2009-01-05 08:27:25 EST
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.
Comment 23 Rex Dieter 2009-01-05 09:21:55 EST
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).
Comment 24 Mary Ellen Foster 2009-01-05 09:26:23 EST
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.
Comment 25 Davide Rondini 2009-01-05 09:57:16 EST
(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.
Comment 26 Ronald Wahl 2009-01-07 15:26:24 EST
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!
Comment 27 Ronald Wahl 2009-01-10 14:15:36 EST
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.
Comment 28 Ronald Wahl 2009-01-10 16:06:34 EST
Created attachment 328639 [details]
Hack to fix the problem (for audio only) (revised)

Last patch contained a crasher... sorry.
Comment 29 Sammy 2009-01-21 13:28:22 EST
This solved the problem for me too....thanks.
Comment 30 Rex Dieter 2009-01-21 13:49:14 EST
Lennart, does the xine-lib patch look sane to you (as a short-term workaround)?
Comment 32 Andreas Utterberg 2009-01-22 04:57:01 EST
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
Comment 33 Sammy 2009-01-22 08:27:22 EST
The above patch also resolved the problem with xine-lib-1.1.16.1.
Comment 34 Rex Dieter 2009-01-23 09:38:36 EST
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.
Comment 35 Fedora Update System 2009-01-23 21:34:34 EST
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
Comment 36 Andreas Utterberg 2009-01-24 02:52:22 EST
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.
Comment 37 Rex Dieter 2009-01-26 09:52:40 EST
> 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.
Comment 38 Andreas Utterberg 2009-01-26 12:18:35 EST
For me the sound works great now with the new fix, both in ff and in Amarok. No errormessages in syslog, nice work!!
Comment 39 Martin Klapetek 2009-01-26 16:53:59 EST
Working as should, nicely done, thanks...
Comment 40 Fedora Update System 2009-01-26 20:50:16 EST
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.
Comment 41 Rex Dieter 2009-02-08 09:16:00 EST
oops, inadvertantly had this auto-close, still waiting on feedback from pulseaudio folks per comment #30
Comment 42 Rex Dieter 2009-02-08 09:18:22 EST
adjusting summary per investigations from comment #27
Comment 43 Martin Klapetek 2009-02-08 11:43:29 EST
(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...
Comment 44 Matthew 2009-03-09 14:40:26 EDT
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
Comment 45 Rex Dieter 2009-03-09 14:47:18 EDT
To be clear, the patch included in fedora's xine-lib builds avoid the initial instability for audio-only streams.  Video requires synchronization.
Comment 46 Lennart Poettering 2009-04-10 10:51:20 EDT
Time should be perfectly stable during stream startup and afterwards with pulseaudio-0.9.15-9

Note You need to log in before you can comment on or make changes to this bug.