| Summary: | amarok-gstreamer high cpu usage with esdsink | ||
|---|---|---|---|
| Product: | [Applications] amarok | Reporter: | Diwaker Gupta <diwaker.lists> |
| Component: | general | Assignee: | Amarok Developers <amarok-bugs-dist> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version: | 1.2-beta1 | ||
| Target Milestone: | --- | ||
| Platform: | Debian testing | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Diwaker Gupta
2004-12-02 08:16:07 UTC
Yeah, it is true that GStreamer-engine does not work well with soundserver sinks. That's why I've already disabled artsdsink. I might disable esdsink too, after reading this bug report. We recommend using alsasink or osssink instead. > ------- Additional Comments From markey web de 2004-12-02 09:12 -------
> Yeah, it is true that GStreamer-engine does not work well with soundserver sinks. That's why I've already disabled artsdsink. I might disable esdsink too, after reading this bug report.
>
> We recommend using alsasink or osssink instead.
Well how does one play nice with artsd then? If I use alsa dmix
plugin, I can't record sounds in KDE since artsd refuses to run in
full duplex mode. With osssink, CPU usages are high and artsd fails to
send sounds to the device if amarok is running.
I guess using the xine engine is the remaining option?
aRts is not developed any longer and has many shortcomings; one of them is the trouble with dmix. So we recommend to simply deactivate artsd entirely. If you need KDE system sounds, you can simply set an external player (like alsaplayer) in the system notification settings. I also find the cpu usage with gst to be pretty high with gst. There appear to be two or three threads that run at about 3.5% each whether music is playing or not. Playback stutters when I do much of anything on the box, like drag scroll the playlist window. I'm using osssink, alsa doesn't seem to work with gst. I found that switching to the xine-engine works ok. The cpu usage runs about 1.5% and playback is much more smooth. The processor on this system is a 1.6Ghz athlon barton. On Sunday 06 February 2005 16:44, John Lash wrote:
> There appear to be two or three threads that run at about 3.5% each whether
> music is playing or not. Playback stutters when I do much of anything on
> the box, like drag scroll the playlist window.
This can easily be fixed by increasing the device buffer in your .asoundrc
(Alsa config file). A value of 32768 or 65536 works nicely for most users.
Still valid? I have a similar problem with amarok-cvs on gentoo. I'm using gstreamer and alsasink. As long as I am playing a file, my cpu usage is minimal. But as soon as I hit stop, or amarok reaches the end of its playlist, my cpu usage goes up to about 50%, and this is on a 3GHz P4. As soon as I hit play again, or kill amarok, cpu usage goes back down. I'm going to recompile with xine support, and will see if xine engine avoids this problem. As I rather suspected, there is no problem with xine instead of gstreamer. I have the same problem using gstreamer with alsasink, but only when using dmix plugin (which I need desperately, because I don't have an emu10k1 card). Strangely, I just have this on one of two similar configured machines... I don't find the difference. Both have a soundcard using intel_8x0 driver, both machines have the same SuSE 9.1, both have amarok 1.2.3 and gstreamer 0.8.9 and both using the same asound.conf with dmix plugin. CPU is fine while playing, as soon as I stop or pause, the CPU is up to 100% (or 50% on a HT CPU of course) I'm all out of ideas... additionally I have sound skips using gst on the machine which makes problems. (buffer size is 65535) Perhaps these problems are related? If xine only could do crossfading... and xine + equalizer would not be so silent... in my case, I am using the beta-2release. On playing the stream http://64.236.34.196:80/stream/1075, kysyguard's vmSize and vmRSS columns had 73,269 and 29,387 respectively. These figures kept increasing slowly but when the stream stopped just a bit for sometime, these figures jumped to 298,340 and 153,612. While observing kysguard I found out that whenever the stream stopped a bit, there would be a big jump in these figures. They rose up to the time the system froze! I am using Kubuntu 5.0.4 and kde 3.4 with amaroK beta-2 and gstreamer0.8.x I recommend using alsasink or osssink instead. These sound-server sinks never worked too well for amaroK. Closing this, for old age. Try again with latest amaroK version. Also, it's likely a GStreamer bug. |