On Saturday 17 January 2009 20:10:04 ext Siarhei Siamashka wrote: > On Saturday 17 January 2009 00:02:09 ext Luiz Augusto von Dentz wrote: > > Hi Siarhei, > > > > It seems gstreamer does have G_BYTE_ORDER, so you probably don't need > > those #ifdef. I also notice some unnecessary white spaces in the of a > > line. > > Hi, > > 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). 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. Best regards, Siarhei Siamashka