Re: SBC big endian issues?

[Marcel Holtmann <marcel@holtmann.org>]

Hi Siarhei,

> > I did not verify that patch thoroughly (I only checked that it compiles)
> > and also seems like I somehow forgot to pass it through 'checkpatch.pl'.
> > Thanks for a good catch.
> >
> > Regarding G_BYTE_ORDER, you are probably right.  I'm not very familiar with
> > gstreamer yet, so somebody else could probably fix this stuff much faster
> > than me.
> >
> > In any case, it probably makes sense to relay all the endian conversion
> > related things to gstreamer and ALSA, and use only native byte order in
> > SBC. This will simplify the code a bit and will make optimizing it easier.
> >
> > I'm quite worried about big endian systems, but I have plans to buy a PS3
> > home in about a month timeframe unless something extraordinary happens  :)
> 
> OK, here is an updated patch.
> 
> Now I also tested GStreamer plugin on qemu mips big endian image. It works
> fine with this change. Having native byte order and not strictly little endian
> is a good idea because all the other gstreamer elements (vorbisdec,
> flacdec, ...) produce output in native byte order. Unless sbcenc uses native
> byte order on this big endian system, audioconvert element is needed to be
> added to gstreamer pipeline and it most likely introduces some extra overhead.
> 
> I did not check ALSA part and probably can't even do this with qemu, but
> removing _LE suffix should also do the job there (according to ALSA
> documentation).

patch has been applied. Thanks.

> Also an interesting observation is that gstreamer is very slow. Using
> gst-launch to encode audio file to SBC is something like 1.5 times slower
> than sbcenc utility when benchmarked on x86 system. I wonder if
> something could be done about this.

I suspected GStreamer to be slower because of its GObject overhead, but
1.5 times is a lot. Not sure if GStreamer or GObject is to blame here.

Regards

Marcel