Strange noise in MP3 playback in Banshee and Amarok, not in mplayer

joonpy · February 13, 2012, 12:19am

Hi,

Sometime ago I have noticed when I play some mp3 files of mine, there are strange noises in the background.
I don’t know how to describe the noise, but it sounds like the sound you hear when you play a tape really fast.

I thought the MP3 files are corrupted or something, so today I found a backup file, but Banshee also made that noise for that file as well.

I found that mplayer plays the exact same file without any noise problem.

I also tried Amarok, and Amarok makes the same noises as Banshee.

I checked my multimedia codecs and made sure all are installed from packman.

Any help would be greatly appreciated. Thanks!

-Joon

joonpy · February 17, 2012, 9:31pm

I’m glad to report that upgrade of gstreamer-0_10-fluendo-mp3 to the one in the update repo fixed this problem.

AKoine · March 25, 2012, 1:11pm

Joonpy, thanks for the tip !!!
I had this problem for months, tried to use xine instead of gstreamer, change various things in phonon config, etc. to no avail.
The only thing is that I used packman repos as default over standard OpenSUSE ones, and had to change that. gstreamer-0_10-fluendo-mp3 from packman (v. 0.10.16-1.2 as of today) is buggy, whereas updating to gstreamer-0_10-fluendo-mp3 from official OpenSUSE repos (v. 12-6.1 as of today) plays all my files ok.

To sum up : I had to change vendor : all my gstreamer-0_10* packages are from packman, except this fluendo-mp3 one. I hope this won’t mess things up later on.

Anyway, cheers for leading me on the track to solve this !

joonpy · March 25, 2012, 4:45pm

You’re welcome. Glad that it was helpful!

-Joon

richardeigenmann · March 1, 2014, 1:20pm

Thanks for posting this thread. My openSuSE 13.1 x64 also picked up the packman gstreamer fluendo plugin which is still broken and injects random garbled sound blobs in the background. I have switched to the openSuSE version and the same mp3 plays fine.

F_Sauce · March 12, 2014, 1:50pm

Another possibility, if you use the packman repo, is to just use the codec provided with the gstreamer ‘bad’ plugin package(s), i.e. don’t install any fluendo package at all; fluendo will take priority if installed.

It’s strange that packman’s fluendo package still is faulty, it has been like this at least since OS 12.2.

Olav

wolfi323 · March 12, 2014, 2:17pm

Well, the actual codec in that package hasn’t changed since 2012:

# rpm -qp --changelog http://packman.links2linux.de/download/gstreamer-0_10-plugins-fluendo_mp3/1647801/gstreamer-0_10-plugins-fluendo_mp3-0.10.18-3.3.i586.rpms | head
* Fre Mai 18 2012 reddwarf@opensuse.org
- update to 0.10.18

* Son Dez 11 2011 reddwarf@opensuse.org
- update to 0.10.16

* Sam Jul 31 2010 Toni Graffy <toni@links2linux.de>
- update to 0.10.14

* Mit Jän 14 2009 Toni Graffy <toni@links2linux.de>

And the last change in the source code’s ChangeLog is from May 7th, 2012 (and the file dates as well).

TBH, I don’t really understand why that package even exists.
openSUSE does include (since 10.3) the latest version in the non-oss repo anyway (even fully licensed! ):

# rpm -qi gstreamer-0_10-fluendo-mp3
 Name        : gstreamer-0_10-fluendo-mp3
Version     : 18
Release     : 2.2.1
Architecture: x86_64
Install Date: Mit 13 Nov 2013 07:18:47 CET
Group       : Productivity/Multimedia/Other
Size        : 1517419
License     : SUSE-NonFree and MIT
Signature   : RSA/SHA256, Son 20 Okt 2013 10:55:58 CEST, Key ID b88b2fd43dbdc284
Source RPM  : gst-fluendo-mp3-18-2.2.1.nosrc.rpm
Build Date  : Son 20 Okt 2013 10:55:42 CEST
Build Host  : cloud119
Relocations : (not relocatable)
Packager    : http://bugs.opensuse.org
Vendor      : openSUSE
URL         : http://shop.fluendo.com
Summary     : GStreamer plug-in from Fluendo for MP3 support
Description :
This package contains the fully licensed MP3 decoder binary as
available from http://shop.fluendo.com free of charge.
Distribution: openSUSE 13.1

This is version 0.10.21 btw, dated March 24th, 2013 (a bit newer than Packman’s 0.10.18 ).

I guess it’s time for a bug report at Packman to either update or drop that package…

wolfi323 · March 12, 2014, 2:31pm

Yes, this should work as well.
I just want to add that you should make sure that gstreamer-(0_10)-plugins-bad is indeed installed from Packman in this case. The package included in openSUSE does of course not contain an mp3 codec (and it will not be switched automatically if you do a 1-click codec install).

F_Sauce · March 12, 2014, 3:33pm

Without fluendo is how I have had it set-up for years. I can’t quite remember but one might also need the plugins-bad-‘additional’ package?

Thanks for the information provided above!

Olav

wolfi323 · March 12, 2014, 5:35pm

Well, I never had a problem with the fluendo codec (the one from the non-oss repo).
But then, I try to avoid gstreamer whenever possible anyway.
Playing back MP3s with the phonon gstreamer backend (or Amarok 1’s gstreamer backend) takes much more CPU time on my system than with xine or VLC, so I prefer those.
I haven’t compared without the fluendo codec yet, though, maybe I should…

I can’t quite remember but one might also need the plugins-bad-‘additional’ package?

No, not for MP3.

The gstreamer-0_10-plugins-bad-orig-addon package contains other stuff like an mpeg2 encoder and codecs for aac or xvid.

But I had a closer look now, and gstreamer-0_10-plugins-bad doesn’t contain the MP3 decoder either (although according to the gstreamer page it should contain libgstmpg123audiodec, which is based on mpg123, but apparently the Packman packages are built without that)
An MP3 decoder is in gstreamer-0_10-plugins-ugly-orig-addon though (based on libmad), together with encoders based on lame and twolame.

And of course there’s always the catch-all gstreamer-0_10-plugins-ffmpeg…

Btw, here’s a list of all official gstreamer codecs and in which plugin package they are (base, good, bad, or ugly):
http://gstreamer.freedesktop.org/documentation/plugins.html

F_Sauce · March 13, 2014, 9:44am

All right my fault, I do tend to mix where the content comes from; should have checked!

Playing back MP3s with the phonon gstreamer backend (or Amarok 1’s gstreamer backend) takes much more CPU time on my system than with xine or VLC, so I prefer those.
I haven’t compared without the fluendo codec yet, though, maybe I should…

I haven’t thought about that, I have both AmaroK and Clementine installed so I can compare them to both (S)MPlayer and VLC.

Earlier I mostly used XINE but more and more software seemed to be dependent on GStreamer so I just followed along.

Olav

wolfi323 · March 13, 2014, 10:33am

If you mean Amarok 2 (i.e. the KDE4 version), this only uses Phonon for playback, so you can use it to compare between gstreamer-0_10 and VLC.
Just switch the Phonon backend, those 2 are available (you may have to install phonon-backend-vlc first though)…
Clementine uses gstreamer-0_10 directly, that’s one of the reasons I never really used it, although I was curious as it’s a fork of Amarok 1.

I guess I really have to test once more, whether the difference in CPU usage is due to gstreamer itself or just the used codec…

Earlier I mostly used XINE but more and more software seemed to be dependent on GStreamer so I just followed along.

Yeah, I preferred xine as well. But unfortunately the phonon-backend-xine is unmaintained since years and therefore has been dropped.
Xine itself is still in development though. But for listening to music I prefer a dedicated music player, like Amarok or Audacious (which uses libmpg123 for playing back MP3s; VLC, MPlayer, and XINE all use libmad btw).

F_Sauce · March 13, 2014, 1:26pm

I just meant between GStreamer (either AmaroK or Clementine), VLC and MPlayer; whether via phonon or not shouldn’t really matter, or should it?

Well, here goes:

Tasks: 213 total,   1 running, 212 sleeping,   0 stopped,   0 zombie
%Cpu(s):  2.9 us,  0.8 sy,  0.0 ni, 96.2 id,  0.0 wa,  0.0 hi,  0.1 si,  0.0 st
KiB Mem:   7911284 total,  1852568 used,  6058716 free,    68688 buffers
KiB Swap:  9062396 total,        0 used,  9062396 free,   805152 cached

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                  
 8991 olav      20   0 6093880 201008  91772 S 10.98 2.541   0:34.14 amarok                                   
 8069 olav      20   0 2661872 110028  46692 S 1.663 1.391   0:27.91 clementine                               
  766 root      20   0  348624 134012 102292 S 0.998 1.694   0:50.71 Xorg                                     
 9705 olav      20   0  304360  30476  22404 S 0.998 0.385   0:00.48 smplayer                                 
 7775 olav      20   0   15356   1648   1132 R 0.333 0.021   0:00.63 top                                      
    1 root      20   0   48216   4036   2296 S 0.000 0.051   0:00.63 systemd                                  
    2 root      20   0       0      0      0 S 0.000 0.000   0:00.00 kthreadd                                 
    3 root      20   0       0      0      0 S 0.000 0.000   0:00.00 ksoftirqd/0                              
    5 root       0 -20       0      0      0 S 0.000 0.000   0:00.00 kworker/0:0H                             
    7 root      -2   0       0      0      0 S 0.000 0.000   0:00.00 rcuc/0                                   
    8 root      -2   0       0      0      0 S 0.000 0.000   0:00.00 rcub/0                                   
    9 root      20   0       0      0      0 S 0.000 0.000   0:00.83 rcu_preempt                              
   10 root      20   0       0      0      0 S 0.000 0.000   0:00.37 rcuop/0                                  
   11 root      20   0       0      0      0 S 0.000 0.000   0:00.62 rcuop/1                                  
   12 root      20   0       0      0      0 S 0.000 0.000   0:00.34 rcuop/2                                  
   13 root      20   0       0      0      0 S 0.000 0.000   0:00.37 rcuop/3                                  
   14 root      20   0       0      0      0 S 0.000 0.000   0:00.00 rcuop/4                                  
   15 root      20   0       0      0      0 S 0.000 0.000   0:00.00 rcuop/5                                  
   16 root      20   0       0      0      0 S 0.000 0.000   0:00.00 rcuop/6                                  
   17 root      20   0       0      0      0 S 0.000 0.000   0:00.00 rcuop/7                                  
   18 root      20   0       0      0      0 S 0.000 0.000   0:00.00 rcu_sched                                
   19 root      20   0       0      0      0 S 0.000 0.000   0:00.00 rcuos/0                                  
olav@DDAdel:~>

This is an output with none of the players playing anything, SMPlayer, AmaroK and Clementine; I haven’t got VLC installed on this computer. I monitored it for a while though and roughly: AmaroK varied between 8 and 13 %, Clementine between 1 and 5 % and SMPlayer between 0 and 2.

AmaroK is indeed power hungry; partly, I suppose, due to the analyser (visual freq tool) which constantly runs. (I tested without - around 4-5%)
Placing Amarok and Clementine down in the tray (deactivating GUI) reduced AmaroK to around 4% and Clementine to 0%

F_Sauce · March 13, 2014, 1:47pm

Here is one with every player playing the same wav file:

%Cpu(s):  4.9 us,  1.8 sy,  0.0 ni, 93.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:   7911284 total,  1891896 used,  6019388 free,    71012 buffers
KiB Swap:  9062396 total,        0 used,  9062396 free,   831076 cached

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                  
 8991 olav      20   0 6155660 210148  92404 S 17.63 2.656   4:10.48 amarok                                   
 8069 olav      20   0 2689096 113500  46744 S 6.321 1.435   1:03.81 clementine                               
  766 root      20   0  348680 137940 104888 S 2.661 1.744   2:04.55 Xorg                                     
 9705 olav      20   0  378660  31928  23056 S 1.663 0.404   0:27.60 smplayer                                 
17696 olav      20   0  500104  21864  14080 S 1.331 0.276   0:02.57 mplayer                                  
    9 root      20   0       0      0      0 S 0.333 0.000   0:01.65 rcu_preempt                              
   12 root      20   0       0      0      0 S 0.333 0.000   0:00.64 rcuop/2                                  
17976 olav      20   0   15380   1684   1132 R 0.333 0.021   0:00.12 top                                      
    1 root      20   0   48216   4036   2296 S 0.000 0.051   0:00.63 systemd                                  
    2 root      20   0       0      0      0 S 0.000 0.000   0:00.00 kthreadd                                 
    3 root      20   0       0      0      0 S 0.000 0.000   0:00.01 ksoftirqd/0                              
    5 root       0 -20       0      0      0 S 0.000 0.000   0:00.00 kworker/0:0H                             
    7 root      -2   0       0      0      0 S 0.000 0.000   0:00.00 rcuc/0                                   
    8 root      -2   0       0      0      0 S 0.000 0.000   0:00.00 rcub/0                                   
   10 root      20   0       0      0      0 S 0.000 0.000   0:00.68 rcuop/0                                  
   11 root      20   0       0      0      0 S 0.000 0.000   0:01.04 rcuop/1                                  
   13 root      20   0       0      0      0 S 0.000 0.000   0:00.73 rcuop/3                                  
   14 root      20   0       0      0      0 S 0.000 0.000   0:00.00 rcuop/4                                  
   15 root      20   0       0      0      0 S 0.000 0.000   0:00.00 rcuop/5                                  
   16 root      20   0       0      0      0 S 0.000 0.000   0:00.00 rcuop/6                                  
   17 root      20   0       0      0      0 S 0.000 0.000   0:00.00 rcuop/7                                  
   18 root      20   0       0      0      0 S 0.000 0.000   0:00.00 rcu_sched                                
olav@DDAdel:~> ^C

Again, turning off the visualiser/analyser part of AmaroK reduced the cpu usage down to around 10%

I have a rather weird cacophonous resonance in my head now.

(S)MPlayer performs much better, as the three players stand on my system now, than the two GStreamer based ones do!

BTW, do you know anything about differences between Gstreamer 0.10 and 1.x performance wise?

wolfi323 · March 13, 2014, 1:53pm

No, but when you test one application (i.e. Amarok) with different backends, this should rule out other variables, and really compare the difference between the backends…
But anyway, I guess we don’t need too scientific here.

This is an output with none of the players playing anything, SMPlayer, AmaroK and Clementine; I haven’t got VLC installed on this computer. I monitored it for a while though and roughly: AmaroK varied between 8 and 13 %, Clementine between 1 and 5 % and SMPlayer between 0 and 2.

Hm. Amarok using ~10% CPU time when idling is a bit unusual I’d say. It takes 6-8% here when playing back MP3s (with the vlc backend).
But I have the Analyzer removed (it doesn’t work with the vlc backend anyway).
And it doesn’t really take any CPU time here when stopped (except for some 0.5% or so sporadically).

Maybe there was some other background task running? (like updating the collection, or some online services)

Anyway, we want to compare the codecs, not the applications, right? So measuring the CPU time while the apps are idling is not really useful.

I will do some tests myself a bit later.

F_Sauce · March 13, 2014, 2:00pm

Tests above done on an Acer Aspire E1-572G, i5 cpu, intel audio-chip and running without PulseAudio.

F_Sauce · March 13, 2014, 2:07pm

No, but when you test one application (i.e. Amarok) with different backends, this should rule out other variables, and really compare the difference between the backends…

Yes, that’s a good point.

Maybe there was some other background task running? (like updating the collection, or some online services)

Might be but I didn’t spot anything.

Thanks,
Olav

wolfi323 · March 13, 2014, 3:32pm

Well, but wav doesn’t need decoding, it is uncompressed. But of course you can measure the application/framework’s overhead that way.

Here’s a quick comparison on my system, playing an MP3 file:

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND  
26234 wolfi     20   0 1233872  91676  17248 S 11,56 4,462   0:33.51 clementine  
27220 wolfi     20   0 1235520  43052   6088 S 10,24 2,096   0:47.66 xine        
31110 wolfi     20   0 1961140  63536  39396 S 9,267 3,093   0:04.66 totem       
31793 wolfi     20   0  840292  40676  24228 S 8,273 1,980   0:03.35 kaffeine-x+ 
27959 wolfi     20   0 1954192  39036   6432 S 7,611 1,900   0:34.59 audacious
31715 wolfi     20   0  722620  43088  28864 S 6,617 2,097   0:04.26 dragon      
25710 wolfi     20   0 4957952 104232  16888 S 6,604 5,073   0:31.31 amarok      
26802 wolfi     20   0 1168292  39684  14412 S 6,288 1,932   0:14.40 vlc         
27271 wolfi     20   0 1400636  29412  11696 S 3,313 1,432   0:14.14 gmplayer

This is a single-core AMD Athlon64 3000+ system.
I ran the apps one after the other (not at the same time), and minimized the player windows, to rule out stuff like analyzers and video performance. (Clementine f.e. used even >30% with the window open and the analyzer active)
Amarok is using the VLC backend here.
dragon is included mainly as comparison to Amarok, because it also uses Phonon.
Kaffeine just uses libxine, so you can see there’s definitely a difference according to the frontend you use… Might be in this case because xine-ui shows an analyzer for audio files whereas Kaffeine doesn’t.

And now Amarok/dragon with the gstreamer-0_10 backend:

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND  
31330 wolfi     20   0 4902568 159468  61940 S 12,90 7,762   0:13.92 amarok      
31692 wolfi     20   0  979156  46620  27716 S 11,91 2,269   0:04.58 dragon

So there is quite a difference, even in RAM usage. That’s why I will keep using phonon-backend-vlc…

Here’s Amarok and totem with the fluendo-mp3 codec removed: (that’s actually the part that interested me most now)

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND 
31452 wolfi     20   0 4894476 153764  62216 S 13,56 7,484   0:11.61 amarok      
31528 wolfi     20   0 1969048  64628  39232 S 9,600 3,146   0:05.29 totem

Not much differently, but the fluendo codec seems to be marginally better regarding CPU usage.

BTW, do you know anything about differences between Gstreamer 0.10 and 1.x performance wise?

Not really, but as you can see, totem (gstreamer 1.x) behaved better here than clementine/Amarok (with gstreamer 0.10), and even xine.
That’s not necessarily only because of gstreamer 1.x vs. gstreamer 0.10, but it seems to indicate that 1.x has better performance.

I can confirm your observation though, that MPlayer uses the least CPU…

wolfi323 · March 13, 2014, 4:40pm

PS, one thing to add: I also tried Amarok 1 with the xine backend now:


  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND     
32403 wolfi     20   0  880028  85724  40776 S 7,924 4,173   0:14.04 amarokapp

So that’s about the same as Kaffeine (not quite unexpectedly).

And with the gstreamer-0_10 backend (yauap, which is a command line player actually, so there are two processes):


  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND     
  381 wolfi     20   0  376256  16080   7148 R 9,240 0,783   0:08.54 yauap       
  323 wolfi     20   0  862216  97316  41560 S 1,320 4,737   0:14.55 amarokapp

A bit better than the other gstreamer-0_10 based players before but still worse than anything else.

And I forgot to mention, that I also have PulseAudio disabled, VIA8237 onboard sound here.

So to sum it up, MPlayer has by far the best performance, with VLC being a good second place.

GStreamer 0.10 is worst, xine and gstreamer 1.x are comparable and somewhere between that and VLC.

I have to say, what surprised me most is that VLC is that good in comparison, and I expected xine to perform better.
I guess I won’t mourn the loss of phonon-backend-xine anymore now…

There was a phonon-backend-mplayer as well, but that never got out of experimental state.

F_Sauce · March 13, 2014, 8:25pm

Interesting to read!
Perhaps it’s more cause to mourn about the loss of phonon’s mplayer backend, I never really tried that one though;

Well, but wav doesn’t need decoding, it is uncompressed. But of course you can measure the application/framework’s overhead that way.

I should actually have known better, I knew this; however, as it might be wav may take compression. But in regard an mp3 codec test this was just stupid of me, I lost focus:shame:
I compared Clementine running an mp3 file to the result of my previous session, it uses a couple + of percentages more staying at around 9%; the cpu load various quite a bit though, but generally this was the case. SMPlayer/Mplayer used around 4% combined playing the same file. I did not make any point of closing the windows; all the test were done with the players in window mode, including these ones (apart from when stated otherwise). All three player were visible during the wav test.