[maemo-developers] DSP SBC encoder task

[From: Felipe Contreras]

On Sat, Jun 7, 2008 at 12:17 AM, Simon Pickering
<S.G.Pickering at bath.ac.uk> wrote:
> 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).

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.

> 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?

In theory it should be fairly easy to create a new GStreamer element
that overrides the software one.

Best regards.

-- 
Felipe Contreras