>>> 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). > > Would it be synchronous? I mean, that the encoding will start with > sbc_encode, and before the function returns the output would be ready. > > I haven't done DSP development, but I've used DSP libraries and all of > them seem to be asynchronous. >
I've re-written the original thread-based (async) code today and it's now synchronous - a call is made to sbc_encode() on the ARM and it's passed through to the DSP and the work is done and the data passed back. This should all fit in without any changes to the code which calls the sbc_* functions. They still call just sbc_init(), sbc_encode() and sbc_close() and all the DSP stuff is handled in the background. If there are parts which need access to lower level data (the example sbcenc code doesn't), then I'll have to write a link in to the DSP to retrieve that data. Not a big issue, but I'll have to take a look at the Bluez code and GStreamer bits to see if this is needed (or someone let me know). A couple of questions still remain about the maximum size of a single PCM or SBC data transfer (so I can make the DSP buffers as small as possible) - any thoughts? Other than that, I'm hopeful it should just drop in to replace the contents of the sbc directory in Bluez-utils and compile and work. I just tried to cross-compile Bluez-utils, and other than the lack of Flex (which is a dep) Scratchbox is complaining about not being able to run binaries it has produced. Any suggestions? Too late in the evening here to do any more today, but I'll get it working tomorrow. > In theory it should be fairly easy to create a new GStreamer element > that overrides the software one. With regard to overriding, I tried a bit of code to look at an env var and choose SW/DSP from that, but it doesn't seem to work. Strange, as I've also written the DSP code so that if the DSP fails for any reason it will fall back to using the sw encoding method (and that works). Probably a silly error I've missed, but it's late so I'll take a look at it tomorrow. The latest code is available in the Garage project under the "mk2" directory if anyone wants to have a play with it while I'm asleep :) Cheers, Simon _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
