After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 558509 - gstreamer / rhythmbox plays mp3 too fast using macports on mac osx leopard
gstreamer / rhythmbox plays mp3 too fast using macports on mac osx leopard
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: dont know
0.10.19
Other All
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-10-30 10:20 UTC by huw
Modified: 2008-10-30 17:19 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24



Description huw 2008-10-30 10:20:56 UTC
Please describe the problem:
I managed to get rhythmbox running using macports to fill in the  
dependancies. However when i play a song it does indeed   
play, but is slightly fast. i think its related to this problem:  http://www.nabble.com/gstreamer-plays-too-fast-td3838139.html 
  but it doesn't provide a solution that helps me. I guess it may  
have  something more to do with gstreamer than rhythmbox in  
particular.  

Steps to reproduce:
1. install macports /xquartz etc
2. compile rhythmbox 0.11.6 using macports to fill in dependencies (such as gstreamer)
3. Run rhythmbox and play mp3


Actual results:
Rhythmbox runs (not perfectly but thats another matter, missing icons etc) and can import mp3 into its library. When you actually play an mp3 it plays a little too fast, such that a 3 minute song is completed in more like 2:30. If you compare the audio to a native mac player like itunes, you can hear the difference.

Expected results:
I would expect the mp3 to play normally.

Does this happen every time?
yes

Other information:
I think its related to http://www.nabble.com/gstreamer-plays-too-fast-td3838139.html where the frequency of the song is perhaps detected incorrectly (like a 44100hz being played back at 48000hz). However, I couldn't find a firm solution or workaround on that site.
Comment 1 Jan Schmidt 2008-10-30 10:56:07 UTC
There was a fix in the OS/X audio sink in gst-plugins-good that sounds like it probably fixed your problem:

2008-08-26  Michael Smith <msmith@songbirdnest.com>

        * sys/osxaudio/Makefile.am:
        * sys/osxaudio/gstosxaudio.c:
        * sys/osxaudio/gstosxaudiosink.c:
        * sys/osxaudio/gstosxaudiosink.h:
        * sys/osxaudio/gstosxaudiosrc.c:
        * sys/osxaudio/gstosxaudiosrc.h:
        * sys/osxaudio/gstosxringbuffer.c:
        * sys/osxaudio/gstosxringbuffer.h:
          Rewrite caps setting and ring buffer initialisation.
          Previously we never told CoreAudio what format we were going to send it,
          so it only worked due to luck, and not at all on some hardware.
          Now we explicitly advertise what formats the hardware supports, and then
          configure the selected one correctly.

You should try release 0.10.11 of the gst-plugins-good module.

Comment 2 huw 2008-10-30 13:12:51 UTC
This worked perfectly. I had to remove gst-plugins-base (the macports version) as well and compile gst-plugins-base then gst-streamer-good and the sound is running at the correct speed.
Comment 3 Michael Smith 2008-10-30 17:19:14 UTC
The version of osxaudiosink in cvs is still pretty terrible. I have a partially-cleaned-up version, but it breaks osxaudiosrc, so I don't want to commit it yet.

The version in cvs will work for slightly more hardware, but fails for a lot of common external (USB, etc) audio devices.