Dear All,
I am trying to implement a custom voice codec on the android bluetooth
platform by linking it, into the A2DP module. I have heard different
versions from different people regarding the licenses (like LGPL and
Apache License). So, before starting my work, I would like to know if
I would be forced to reveal my source code, once I implement my codec
on BlueZ stack. Please let me know, so that I can choose my platform,
before starting my work.
Regards,
Madhavi.
On Tue, Aug 10, 2010 at 2:49 AM, Luiz Augusto von Dentz
<[email protected]> wrote:
> Hi,
>
> On Mon, Aug 9, 2010 at 10:37 PM, Pavan Savoy <[email protected]> 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
>
Hi,
On Mon, Aug 9, 2010 at 10:37 PM, Pavan Savoy <[email protected]> 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.
--
Luiz Augusto von Dentz
Computer Engineer
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 ...
On 8/9/10, Luiz Augusto von Dentz <[email protected]> wrote:
> Hi,
>
> On Fri, Aug 6, 2010 at 6:44 PM, Madhavi Manchala
> <[email protected]> wrote:
>> Dear All,
>>
>> I am trying to implement a custom voice codec on the android bluetooth
>> platform by linking it, into the A2DP module. I have heard different
>> versions from different people regarding the licenses (like LGPL and
>> Apache License). So, before starting my work, I would like to know if
>> I would be forced to reveal my source code, once I implement my codec
>> on BlueZ stack. Please let me know, so that I can choose my platform,
>> before starting my work.
>
> If you are just implementing a new codec then you might have to link
> to GPL code which basically makes your code GPL too, but we have plans
> to support this over dbus which wouldn't require you to link to any
> GPL, instead you register an endpoint which will be used to configure
> streams.
>
> This code can be found here:
>
> http://gitorious.org/~vudentz/bluez/vudentzs-clone/commits/endpoint
>
> This depend on dbus 1.3.1 and latter which will probably only reach
> upstream once we have a dbus 1.4 release.
>
> --
> Luiz Augusto von Dentz
> Computer Engineer
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
> in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Hi,
On Fri, Aug 6, 2010 at 6:44 PM, Madhavi Manchala
<[email protected]> wrote:
> Dear All,
>
> I am trying to implement a custom voice codec on the android bluetooth
> platform by linking it, into the A2DP module. I have heard different
> versions from different people regarding the licenses (like LGPL and
> Apache License). So, before starting my work, I would like to know if
> I would be forced to reveal my source code, once I implement my codec
> on BlueZ stack. Please let me know, so that I can choose my platform,
> before starting my work.
If you are just implementing a new codec then you might have to link
to GPL code which basically makes your code GPL too, but we have plans
to support this over dbus which wouldn't require you to link to any
GPL, instead you register an endpoint which will be used to configure
streams.
This code can be found here:
http://gitorious.org/~vudentz/bluez/vudentzs-clone/commits/endpoint
This depend on dbus 1.3.1 and latter which will probably only reach
upstream once we have a dbus 1.4 release.
--
Luiz Augusto von Dentz
Computer Engineer
On Mon, Aug 9, 2010 at 4:32 PM, Siarhei Siamashka
<[email protected]> wrote:
> On Monday 09 August 2010 07:38:17 Madhavi Manchala wrote:
>> By the way, please let me clarify one thing. I think, the input for
>> the SBC module is the RAW stream. Am I correct?
>
> As I understand it, you are not happy about something in bluez so that you are
> considering to hook in your own SBC implementation. Could you please share your
> concerns? Do you have problems with sound quality? Performance in general?
> Performance on some particular hardware? Anything else? Are you interested in
> SBC encoder or decoder?
Actually, I am not trying to hook a new SBC implementation. I am
trying to work on a new custom codec, and in case the SINK devices do
not support my custom codec, I want the src to reroute the stream
through the SBC encoder, so that all the SINK devices will work
without any problem. Since SBC is mandatory in the A2DP
implementation, I thought about using SBC as the alternate codec.
Please let me know if I am missing something.
Thanks and Regards,
Madhavi M.
On Monday 09 August 2010 07:38:17 Madhavi Manchala wrote:
> By the way, please let me clarify one thing. I think, the input for
> the SBC module is the RAW stream. Am I correct?
As I understand it, you are not happy about something in bluez so that you are
considering to hook in your own SBC implementation. Could you please share your
concerns? Do you have problems with sound quality? Performance in general?
Performance on some particular hardware? Anything else? Are you interested in
SBC encoder or decoder?
Starting a new topic about these technical things may be a good idea.
--
Best regards,
Siarhei Siamashka
On Sat, Aug 7, 2010 at 6:58 PM, Alan Carvalho de Assis
<[email protected]> wrote:
> Hi Madhavi,
>
> On 8/7/10, Marcel Holtmann <[email protected]> wrote:
>> Hi Madhavi,
>>
>>> I am trying to implement a custom voice codec on the android bluetooth
>>> platform by linking it, into the A2DP module. I have heard different
>>> versions from different people regarding the licenses (like LGPL and
>>> Apache License). So, before starting my work, I would like to know if
>>> I would be forced to reveal my source code, once I implement my codec
>>> on BlueZ stack. Please let me know, so that I can choose my platform,
>>> before starting my work.
>
> As you asked this same question in Android mailing list I suggest you
> to forward Marcel reply to here as well. This way many other people in
> that list will be aware of it.
>
> Best Regards,
>
> Alan
Thanks to Marcel and Alan.
By the way, please let me clarify one thing. I think, the input for
the SBC module is the RAW stream. Am I correct?
Thanks and Regards,
Madhavi M.
Hi Madhavi,
On 8/7/10, Marcel Holtmann <[email protected]> wrote:
> Hi Madhavi,
>
>> I am trying to implement a custom voice codec on the android bluetooth
>> platform by linking it, into the A2DP module. I have heard different
>> versions from different people regarding the licenses (like LGPL and
>> Apache License). So, before starting my work, I would like to know if
>> I would be forced to reveal my source code, once I implement my codec
>> on BlueZ stack. Please let me know, so that I can choose my platform,
>> before starting my work.
As you asked this same question in Android mailing list I suggest you
to forward Marcel reply to here as well. This way many other people in
that list will be aware of it.
Best Regards,
Alan
Hi Madhavi,
> I am trying to implement a custom voice codec on the android bluetooth
> platform by linking it, into the A2DP module. I have heard different
> versions from different people regarding the licenses (like LGPL and
> Apache License). So, before starting my work, I would like to know if
> I would be forced to reveal my source code, once I implement my codec
> on BlueZ stack. Please let me know, so that I can choose my platform,
> before starting my work.
BlueZ (bluetoothd and libbluetooth) is licensed under GPL 2.0 license
and nothing else. It is pretty clear in the COPYING file. There are a
few source code files licensed under LGPL, but after linking the end
result is still GPL. If in doubt ask your lawyer since nobody here on
the mailing list can give you official legal advise.
Regards
Marcel