Hi there,

before I start, could someone please try to "playback" an MP3 on a kirkwood target (no soundcard required):

gst-launch-1.0  filesrc location=file.mp3 ! id3demux ! fakesink -t

required packages: gstreamer1-utils, gst1-mod-id3demux, gst1-mod-typefindfunctions

I have been trying this for some time now, compiling different versions of gstreamer and always getting the same errors.

ERROR: from element /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstID3Demux:id3demux0: Could not detect type of contents

Running with some more verbose debug output (--gst-debug="*:4") I could see that gsttypefindfunctions.c did not correctly identify the MP3 after the third header. I then modified the source to only check the first two headers (five would be normally required).
Now there is a problem with mpegaudioparse complaining about invalid bitrate, samplerate, etc.

I suspect this to be some kind of endianness problem - unfortunately I am no C programmer at all, therefore I have no idea what to do next in order to fix this...
I am crosscompiling on x86_64 - but so is the openwrt buildbot I guess.

Alex

PS: I compiled various versions of Gstreamer; v1.2.4 on my debian wheezy (ppc) works fine

Sorry, if I haven't been more clear the first time...

In my opinion the Gstreamer packages for Kirkwood are faulty starting with Chaos Calmer and they still are with Trunk.
I used the ones compiled by the buildbot as well as my own (different versions, all running fine on AR71xx)

I opened a ticket with the Gstreamer guys at Gnome:
https://bugzilla.gnome.org/show_bug.cgi?id=762224

Unfortunately this is a show stopper while trying to run a new upnp/dlna renderer on my Pogoplug E02.

Now is the code faulty (in regards to cross-compiling for a different architecture), or are some of the cross-compiling arguments set wrong?