[maemo-developers] DSP SBC debugging

[From: Simon Pickering]

> > > DEBUG: _snd_pcm_bluetooth_open: Bluetooth PCM plugin (Playback)
> > > DEBUG: audioservice_send: sending BT_GETCAPABILITIES_REQ
> > > DEBUG: audioservice_recv: trying to receive msg from audio service...
> > > DEBUG: audioservice_recv: Received BT_GETCAPABILITIES_RSP
> > > alsa-lib: pcm_bluetooth.c:1589:(bluetooth_init) BT_GETCAPABILITIES  
> > > failed : Input/output error(5)
> > > alsa-init: playback open error: Input/output error
> > > Could not open/initialize audio device -> no sound.
> > > Audio: no sound
> > > Video: no video
> > > 
> > > Exiting... (End of file)
> > > (none):/home/user/MyDocs/.sounds#
> > 
> > Good news, I also get this error with the standard un-DSP-enabled
> > bluez-utils-3.28. So it's (probably) not my fault. It would still be
> > interesting to know why it happens mind you as I'd like to 
> > use a2dp. Does
> > a2dp work for anyone else using Diablo?
> 
> Ah, user error - need to re-pair the headset. Sorry for the noise. Ball's
> back in my court now, some more DSP code debugging to do (it doesn't seem
to
> like the type of data that's being passed to it, which is not unexpected
as
> it's only been tested using one type of input file thus far).

Right, well goodish news, the dsp sbc encoder appears to work. It can be
used with mplayer to play ~1s of audio, then it all goes quiet. If you pause
until the tone of the quietness changes, you can start again and perhaps
play another second's worth of data, etc. I'm assuming that this is caused
by the DSP not being able to encode fast enough. I'm curious as to why no
error is raised by Bluez/ALSA though - anyone know?

So, if the encoding process is indeed too slow, I need to speed it up. One
thing to do would be to look at the actual processing, which although I've
altered it to use 16bit chars, I've not optimised in any way to use the
DSP's features (or any ASM). I'm a bit surprised if this is the problem
though as I understood that the code could run in real-time on a 200MHz
StrongARM chip, I'd thought the DSP would be able to also run it without any
tweaks?

Another thing to look at is the overhead associated with doing the
processing on the DSP - this is down to how we transfer the data pretty
much. Atm I'm using private bulk transfers, which afaik require no memcpys
on the DSP, and presumably a single one when the ARM code calls write() or
read() on the DSP dev device.

I could equally use normal bulk transfers, which I think could be used to
need the same number of memcpys as above.

The final option is to use shared memory to perform the data transfer. This
doesn't eliminate any memcpys afaict as the data is passed into sbc_encode()
as a pointer & length and must then be copied to the shared memory (in the
same way as it would be passed with write() in a bulk transfer). In addition
some sort of communication is still required between the ARM & DSP to ensure
that they remain synchronised. Rather than polling on the DSP, one would
probably use word transfers. I'm assuming these have the same overheads as a
bulk transfer (though they have less data to move) so there will be no net
gain from using this technique either.

Another thing to look at is how fast an ioctl() call to the DSP dev device
is performed as opposed to a word transfer using write() as this is another
method of signalling the DSP from the ARM.

Anyway, what I'm saying is that at first glance I can't really see a faster
way of transferring the data across (though I will do some testing to see
what the cold hard figures say), but if anyone spots a mistake or two in my
logic please pipe up.

Next step is to compare the running times of the DSP code vs. the ARM code
(to reassure myself that this really is an issue with the code speed and not
something else) and then to look at optimising the innards of the sbc
encoder to take advantage of the DSP's features.

Sorry for the long and rambling post, just though some of you might like to
know where I am,

Cheers,


Simon