[maemo-developers] DSP SBC encoder task

[From: Simon Pickering]

> 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 :)
>

Right, I've created some binary DSP modules, which are available for  
the 770 and os2008 (chinook) devices for download from the Garage  
page. The SBC code seems to drop straight into the bluez-utils-3.32  
code (certainly it compiles), however there is an error when I move  
the updated bluez-* files over to my N800 test machine and try running  
mplayer over a2dp. I think this basically means I'll need to recompile  
something else. If anyone knows what, or fancies having a go please  
speak up :)

The error (returned by mplayer) is:

Nokia-N800-50-2:/home/user/MyDocs/.sounds# mplayer Moby-In_My_Heart.mp3
MPlayer 1.0rc1-maemo.27.n8x0 (C) 2000-2006 MPlayer Team
CPU: ARM
Internet Tablet OS version: RX-34+RX-44_2008SE_2.2007.50-2_PR_MR0

[MENU] Can't open menu config file: /root/.mplayer/menu.conf
Menu inited: /etc/mplayer/menu.conf

Playing Moby-In_My_Heart.mp3.
Cache fill:  0.00% (0 bytes)
Audio file file format detected.
==========================================================================
Trying to force audio codec driver family dspmp3...
Opening audio decoder: [dspmp3] MP3 audio pass-through for Nokia  
770/N800 (fake decoder)
ADecoder preinit failed :(
ADecoder init failed :(
Trying to force audio codec driver family libmad...
Opening audio decoder: [libmad] libmad mpeg audio decoder
AUDIO: 44100 Hz, 2 ch, s16le, 128.0 kbit/9.07% (ratio: 16000->176400)
Selected audio codec: [mad] afm: libmad (libMAD MPEG layer 1-2-3)
==========================================================================
alsa-lib: pcm_bluetooth.c:1505:(audioservice_recv) Error receiving  
data from audio service: Success(0)
alsa-lib: pcm_bluetooth.c:1521:(audioservice_expect) Bogus message  
BT_GETCAPABILITIES_REQ received while BT_GETCAPABILITIES_RSP was  
expected
alsa-init: playback open error: Invalid argument
Could not open/initialize audio device -> no sound.
Audio: no sound
Video: no video


Exiting... (End of file)


Which looks like some sort of API change. I'm not sure if libasound.so  
needs to be recompiled (though I seem to get a plugin for it when  
compiling bluez-utils, so I'm doubtful), or if mplayer needs to be  
recompiled (which I'll try in a minute to see).

Anyway, as I said, the DSP binary (and source) code (which tends to be  
the limiting factor with people playing with these things) is  
available for download, so all you then need to do is use the sbc  
source from the Garage repo and compile away and test things.

Let me know if it works :)

Cheers,


Simon