On Tue, Aug 10, 2010 at 2:49 AM, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > Hi, > > On Mon, Aug 9, 2010 at 10:37 PM, Pavan Savoy <pavan_savoy@xxxxxxxx> wrote: >> As long as we are updating, can the liba2dp be abstracted out of not >> only the sbc encoding part but also the sending over UART part (as in >> transport ...) >> >> chips are getting smarter and the sbc codecs are moving to either a >> co-processor/dsp or even inside the BT chip itself, so we might have >> to send the PCM raw data somewhere else for the dsp to encode to sbc >> and send it over the air ... >> >> currently the data (sbc/pcm) and the control (connection >> establishment) is too tightly sort of coded in together.. isn't it ? >> >> for something like the above to happen our liba2dp had to be almost >> re-written ... > > Im afraid liba2dp is some android specific thing, not upstream, and as > I said before upstream is probably going to use dbus to pass the fd > around, so this is probably not relevant here. May be but isn't the same in pcm_bluetooth plugin too ? If I had to support such a feature where I am only bothered about the connection/control path and don't have to bother about data, how best can I make use of this pcm_bluetooth ? Specifically, I need something only to set-up the stream and the bluetoothd being in START_STREAM sort of state, and the data is being pumped into say another alsa-sink which is connected to dsp's pcm input or h/w sbc encoder's pcm input. PS: sorry for the noise... i am just thinking aloud here, And yes we do have a sort of working way on bluez to support such things, but it involves hacked up code where we sort of comment out the pieces of code... > Luiz Augusto von Dentz > Computer Engineer > -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
