> > > 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 _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
