GNOME Bugzilla – Bug 133778
Delay when switching between songs
Last modified: 2006-01-12 10:13:53 UTC
rhythmbox version : 0.6.5 287 titles in the library. There's a long delay (up to 3 seconds) when changing song. It happens when pressing play, go to next/previous song or between songs during playing. Please find attached a trace captured whith strace -Tr, during when I press play, then go to next song then quit. You'll find sys calls that lasts more than 1 second. Hope it helps. Regards, Emmanuel.
Created attachment 24198 [details] Ziped trace
Additional info: It happens when system/gstreamer/default/audiosink = osssink. There's no delay when this key is set to esdsink.
Moving this to GStreamer. What version of GStreamer do you use with this version of Rhythmbox? Does it still occur with the recent GStreamer releases? For any GStreamer people reading this, do you think it could be something to do with the PropertyProbe stuff that is in osssink?
It was with gstreamer serie 0.6, but I don't remember the exact version number. It was the current gstreamer from debian sid at the time I did the report. I use currently gstreamer 0.8.1-2 from alioth and the delay between to songs is much more shorter, but still audible, using osssink. There's absolutly no audible delay when I use esdsink. If you want, I can make strace files with gstreamer 0.8.1-2.
Yeah, that might help. What version of linux do you use? What sound card do you have? Do you use OSS native, or OSS through ALSA emulation? If so, what version of ALSA do you use?
I can also reproduce this bug. I am running Debian "unstable" with Linux 2.6.4 (ALSA 1.0.4). I have installed Rhythmbox 0.8.3 and GStreamer 0.8.1 from Debian "experimental". My audio device is the onboard sound on my NForce2 system (Intel 810 driver). When I am using GStreamer's osssink on top of ALSA OSS emulation, there is a delay between songs. When switching songs, the CPU usage goes to 100% for about a second, and the system becomes unresponsive (the mouse cursor becomes jerky, for example). The problem occurs only when I am using osssink with the ALSA driver (snd_intel8x0) and OSS emulation. The problem does not occur if I switch to the OSS driver (i810_audio). alsasink does not work at all on this system (I'll file a separate bug for this, after checking the existing bugs; may be related to bug 140432): $ gst-launch-0.8 filesrc location=file.mp3 ! spider ! alsasink RUNNING pipeline ... gst-launch-0.8: pcm_plug.c:882: snd_pcm_plug_hw_params: Assertion `err >= 0' failed. Aborted (core dumped)
Note: The problem with alsasink in comment 6 is filed as bug 134007.
manu@emmanuel:~$ uname -a Linux emmanuel 2.4.25 #1 dim avr 18 12:43:02 CEST 2004 i686 GNU/Linux lspci -v 0000:00:0f.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 06) Subsystem: Ensoniq Creative Sound Blaster AudioPCI64V, AudioPCI128 Flags: bus master, slow devsel, latency 32, IRQ 10 I/O ports at b400 [size=64] Capabilities: [dc] Power Management version 1 I use OSS through ALSA 1.0.4. I'm going to attach two outputs of a strace -Tr, one with esdsink, the other with osssink. During this trace, I launch rhythmbox, press play button, then next, next again, then stop and quit. Looking at the trace whith osssink during execution, it seems pauses occur at a writev preceded by a sigrtsuspend, close(20), close(21) (line 7004 for example).
Created attachment 27489 [details] strace -Tr with esd (tgz)
Created attachment 27490 [details] strace -Tr with oss (tgz)
That it only happens with oss emulation would imply its another alsa bug? The "pcm_plug.c:882: snd_pcm_plug_hw_params: Assertion `err >= 0' failed." problem is an alsa bug which is listed on their bugtracker, but I forget the number.
Oh, I should read other comments, its bug #134007
Marking as duplicate then. Emmanuel: attaching straces *ARE NOT USEFUL* unless someone explicity asks for them. They just take up space on our server - please don't bother unless someone asks you for an strace. *** This bug has been marked as a duplicate of 134007 ***
"oops" Sorry, reopening, this bug is about a different issue.
I cannot reproduce this bug anymore. I am now using GStreamer 0.8.6, Rhythmbox 0.8.8, ALSA 1.0.7, and Linux 2.6.9.
Assuming it's fixed then. Emmanuel, please reopen if it's not fixed for you when using the same version as Matt.
Same setup as Matt here, except for linux which is 2.6.8. The problem is still there for me, but with a smaller delay between song (less then one second, but noticeable). It happens with osssink and alsasink. Everything work fine with esdsink. My test setup is simple. Open the following files with rhythmbox: http://emmanuel.pacaud.free.fr/bugs/rhythmbox/test1.mp3 http://emmanuel.pacaud.free.fr/bugs/rhythmbox/test2.mp3 Double click on first file, then double click on second file. With esdsink, there's absolutly no silence between the two files.
It's related to plugging time. Esdsink caches internally and thus doesn't expose the bug. We need to cache next songs before the previous one is finished, and don't do that yet. Marking enhancement (and yes, I know that it's annoying for live albums; it's still an enhancement, though).
*** Bug 140275 has been marked as a duplicate of this bug. ***
I'm experiencing this too, the delay is ~1 second. I'm using Debian unstable with linux 2.6.9, Rhythmbox 0.8.8 and gstreamer with alsa. The following debs are installed for gstreamer: libgstreamer0.8-0_0.8.9-2_i386.deb gstreamer0.8-alsa_0.8.8-3_i386.deb This is very annoying when playing live albums, or albums where songs continue over several tracks.
Not sure exactly what the problem being reported is. Is it (1) that GStreamer 0.8 takes too long between sequential audio pipelines, or (2) that rhythmbox doesn't support gapless playback? If (1), that problem is almost gone in 0.10. I don't notice a gap at all between songs in Jamboree, so it's probably the same in rhythmbox. If (2), that's something that rhythmbox will have to support. It involves prerolling a pipeline and hooking it up to some kind of stream switcher. It's a pipeline topology issue, not a GStreamer issue. For example Flumotion's jukebox component does gapless playback with 0.8. In any case this is not a GStreamer problem. Reassigning to Rhythmbox; suggest that you all test this with 0.10 and see if the 0.10 responsiveness is a problem for you. If so, then work on gapless playback.
With GStreamer 0.10 the gap between songs in Rhythmbox is virtually non-existant. Supporting actual gapless playback (and possibly cross-fading) is bug 130426, so marking as a duplicate of that. *** This bug has been marked as a duplicate of 130426 ***