Hi Chaps, > I have been thinking more about this and I think another approach > could be considered. > > It would be easier to plug your work into everything else if you wrote > it up as a patch to the regular sbc.c so it transparently chooses the > soft or dsp codec at runtime. It would work with the alsa plugin, gst, > and eventually pulse without extra work. > > Marcel will have to weigh in if it's to be accepted upstream. > > In any case, we'd need an override. It could be done with an > environment variable like "SBC_CODEC" with values eg "soft", "dsp", > "auto" with auto the default if it's not set. This does step around > gstreamer a little, but anyway, alsa and pulse don't have the greatest > gstreamer integration to start with...
Yes, that sounds like a good idea. At the moment I'm effectively running all of sbcenc.c on the DSP, while I should just be doing sbc_encode() + whatever init and clean-up routines are needed to handle the DSP on the ARM and to pass it the stream format data. I've started looking at the Bluez code and it looks like it should be reasonably easy (he says!) to have just these bits running on the DSP (expect lots of questions still though). What do you mean by it stepping around GStreamer? From my quick look at the code, the same init/clean-up and sbc_encode() routines seem to be used for both GStreamer and the ALSA bits; what more does GStreamer need to know? Cheers, Simon _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
