Controls are sluggish

[Trouilliez vincent]

When playing an MP3 playlist, there appears to be a little lag/delay between the
time you click on a button (pause/play/next/previous/volume control), and the
time where things actually happen.

Both Totem-Gstreamer and Totem-Xine are affected, but Totem-Xine is somehow
significantly better than Totem-Gstreamer, detail as follows :

Control T-Gstreamer T-Xine
----------------------------------------
previous 1s lag responsive
next 1s lag responvise
stop 1s lag responsive
play/resume 0.5s lag 0.5s lag
seek bar 0.5s lag responsive
volume control 1s lag 0.5s lag

other: both versions occasionally produce sound "clicks"/"glitches" when using
the seek bar or the stop button.

--
Vince

[Sebastien Bacher (seb128)]

that's not that slow here. What kind of computer do you have ? do you have the
issue with alsasink or osssink (you can change them in gstreamer-properties)

[Trouilliez vincent (vincent-trouilliez-modulonet)]

> that's not that slow here.

So that's just me then ?? Bad luck :-/

> What kind of computer do you have ?

An AMD Athlon XP 1700+ (about 1.45GHz), 512MB of PC2100 DDR RAM, with a nForce
chipset Motherboard (MSI K7N420 Pro), sound chip is AC '97 compatible

> do you have the issue with alsasink or osssink (you can change them in
gstreamer-properties)

Where do I change these "gstreamer-properties" ? In Warty, and in Hoary ?

[Sebastien Bacher (seb128)]

esound/polypaudio probably uses the devices so you need to turn it the time to test.
alt-f2, gstreamer-properties on warty or hoary. You can find it as 'Multimedia
Systems Selector' ('Sélecteur de systèmes multimédia') in hoary

[Trouilliez vincent (vincent-trouilliez-modulonet)]

(In reply to comment #3)
> esound/polypaudio probably uses the devices so you need to turn it the time to
test.
> alt-f2, gstreamer-properties on warty or hoary. You can find it as 'Multimedia
> Systems Selector' ('Sélecteur de systèmes multimédia') in hoary

Okay found it. In the "Audio" tabn I selected OSS the ALSA. But that doesn't
change anything, totem and Rhythmbox nexT/previous/volume controls still aren't
responsive.
I installed XMMS, and all the controls work beautifully and react at the speed
of light. So it's got to be a problem inherent to Rhytmbox and Totem ?

[Sebastien Bacher (seb128)]

totem uses gstreamer and xine depending of the package, rhythmbox uses
gstreamer, you can probably blame gstreamer and xine ... weird, gstreamer is
getting better and xine works fine usually

[Trouilliez vincent (vincent-trouilliez-modulonet)]

> totem uses gstreamer and xine depending of the package, rhythmbox uses
> gstreamer, you can probably blame gstreamer and xine ... weird, gstreamer is
> getting better and xine works fine usually

That probably means that the problem is not in the underlying libraries
themeselves, but the way the GUI uses the libraries ?
Anyway, it's frustrating to hear that the controls are responsive on others
machines, but just not on mine. On the other hand, it brings hope : when I get
round to upgrading my machine, maybe this problem will cure itself...
I wish I had local Ubuntu friends to compare things, but the only Linux chap I
know, is a Mandrake fan and likes KDE, so I am having a hard time trying to get
him to use Ubuntu... :-/

[Sebastien Bacher (seb128)]

*** Bug 13414 has been marked as a duplicate of this bug. ***

[Sebastien Bacher (seb128)]

do you still have this issue?

[Trouilliez vincent (vincent-trouilliez-modulonet)]

Hi Seb,

Yes, I have upgraded to Hoary stable now, albeit still running the Warty kernel
due to a bug with the TV card in the Hoary Kernel, and Gstreamer's slugishness
is still there both with Totem and Rhythmbox. And Totem-Xine is still a lot more
responsive than Totem-Gstreamer, somehow.

[DarkMageZ (darkmagez)]

can you still feel this sluggishness in dappper or edgy? i can't seem to notice a difference between the new gstreamer (0.10) vs xine as far as control sluggishness goes.

[Trouilliez vincent (vincent-trouilliez-modulonet)]

Yes it's still sluggish. It has improved though: the next, previous, and seek bar controls are now responsive. However the play, pause, and volume controls still suffer noticeable lag.

[Sebastien Bacher (seb128)]

Do you still get the bug on feisty?

[Trouilliez vincent (vincent-trouilliez-modulonet)]

I don't know, Feisty is not out yet. In Edgy, the play/pause, and volume control, still suffer noticeable/annoying lag.

I will upgrade to Feisty when it's out, later this week hopefully, and report back...

[trollord (trollenlord)]

Is this still valid?

[Trouilliez vincent (vincent-trouilliez-modulonet)]

> Is this still valid?

It has improved a lot (gstreamer version).

Only remaining issues is a little lag in the volume control, and the seek bar which produces glitches because it keeps playing the music WHILE the seek bar is being operated, instead of waiting for user to release the mouse button, to resume playback.

Maybe I should open a new/seperate bug regarding the seek bar issue, to keep things tidy in the bug tracker and make it easier to follow up ?

[Pedro Villavicencio (pedro)]

Is this still present in Gutsy?

[Trouilliez vincent (vincent-trouilliez-modulonet)]

I don't know, Gutsy has not been released yet !
I will try again once it is out and I have upgraded to it...

[Sebastien Bacher (seb128)]

do you still get the issue in hardy or intrepid?

[Trouilliez vincent (vincent-trouilliez-modulonet)]

Yep, Volume control still sluggish (0.5 second lag) in Hardy.

Intrepid has just been released, I will install it and report back soon.

[Trouilliez vincent (vincent-trouilliez-modulonet)]

> Intrepid has just been released, I will install it and report back soon.

I just upgraded to Intrepid, same problem.

[Sebastien Bacher (seb128)]

not sure if the issue is specific to your configuration or if you are being very picky on this delay, anyway letting the bug unconfirmed for now we got no duplicate and it's fast enough on all my installations

[Trouilliez vincent (vincent-trouilliez-modulonet)]

> not sure if the issue is specific to your configuration

I don't think so, because since reporteing this bug years ago, I have recently replaced my botherboard, which means new sound chip (was AC97, now Intel HDA/ ALC 888), and it didn' thave any influence on the problem.

> or if you are being very picky on this delay

I don't think I am being picky : all volume controls in gnome-control-panel are, and have always been, perfectly responsive/real-time, zero delay, so I genuinely (naively?) expected applications specific voluime contorls (be it Totem or Rhythmbox or whatever) to also be snappy.

> it's fast enough on all my installations

fast "enough". So you acknoledge thereby that it's not fast. CQFD ! ;-)

Anyway, I see you are getting bored with this bug and so am I (given it's clear nothing will be done about it), so let's just mark it "Won't fix" and let it rot. I give up...

[Sebastien Bacher (seb128)]

the actions as fast enough to not notice enough lag here, I would not say that's slow, anyway the bug is low importance but there is no reason to close it if that's a real issue for some users, it should just be sent to bugzilla.gnome.org by somebody having the bug and who can reply to upstream comments and try change

[Martin Mai (mrkanister-deactivatedaccount-deactivatedaccount)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Can you try with the latest Ubuntu release? Thanks in advance.

[Omer Akram (om26er)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!