GstA2dpSink was extending GstAudioSink, but there is a problem in that,
GstAudioSink expects only
"audio/x-raw-int", "audio/x-raw-float", "audio/x-mulaw" or "audio/x-alaw" as
media types. GstA2dpSink should support mp3 and sbc, that's causing a
runtime error. This patch changes the base class from GstAudioSink to
GstBaseSink, changing the stub functions to be implemented also.
Best regards,
Thiago
Hi Luiz,
> > > My name suggestion is: libbtaudio
> >
> > no extra library. Period. I am serious about it. We simply link the
> > plain object file twice.
>
> I confused, do you agreed or not to create the LGPL library?
we create an object file (like for any other *.c files) under LGPL and
then simply link them.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
On 10/9/07, Marcel Holtmann <[email protected]> wrote:
> Hi Luiz,
>
> > My name suggestion is: libbtaudio
>
> no extra library. Period. I am serious about it. We simply link the
> plain object file twice.
I confused, do you agreed or not to create the LGPL library?
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Luiz,
> My name suggestion is: libbtaudio
no extra library. Period. I am serious about it. We simply link the
plain object file twice.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Fabien
On 10/9/07, Fabien Chevalier <[email protected]> wrote:
> I was more thinking of as a complete rewrite of ipc.h (we should find it
> another name btw : lets call it newipc.h for now ;-) ).
> I already started thinking to how i would like to see it look.
> It should be relatively lightweight, expose directly a message based API
> (as you would find on most RTOS), with just a few functions to create
> and free a session to the audio daemon, and to retrieve the data socket,
> so that each user wouldn't have to know the tricks about ancilliary data
> passing :-)
> I fact it should be so lightweight that i think we could static inline
> all the functions, and thus we wouldn't even need a *.c file.
>
> I'm waiting for comments, int the meantime i'm gonna start drafting a
> newipc.h :-)
Good, I need to rework ipc anyway since there is no capabilities exchange
between the daemon and the plugin and that cause some problems to make
plugin able choose codec parameters. Right now the daemon choose the best
option it find and return to plugin, we should change that so the plugin could
get the device capabilities and choose the best option by it own.
Thiago is having a good progress with gstreamer plugin, so this is a very good
opportunity to work together and make it happen.
My name suggestion is: libbtaudio
Btw I have no problem with LGPL.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel, Luiz, Johan, Brad,
>
>> Well, *I do* care.
>> As i told you back in Montpellier, i need a way to plug an external
>> (proprietary) hardware accelerated audio system onto the audio service.
>> In fact i could start working on such a library right away, provided
>> that it is LGPL, so that i can link a proprietary stuff on top of it.
>> Even if it is not packaged as an external library at first, provided i
>> can somehow copy the code out of bluez tree and rebuild a LGPL library
>> out of it would be acceptable as a first step. :-)
>
> I am okay with that. That is not the problem. Having that code under
> LGPL license is no big deal for me. I am actually fully okay with that.
> However please remember that my default license will always be GPL and
> you really have to tell me if you want something different.
Ok, I 100% agree with you : GPL per default, LGPL for "some special
bits" :-)
>
>> If that can't be done then i'm gonna go grumble in a corner and we will
>> have missed an opportunity to move the bluez audio system forward. :-(
>> And remembering what Marcel told us during the meeting, the IPC API is
>> not public because "we don't really know what we're doing".
>> My answer to that is:
>> - having worked on audio stuff for some time now, i think i know what
>> i would be doing if i was to work on this API : which mean it would be
>> made stable pretty quickly.
>> - We'd better start stabilizing the API before too much effort has
>> been put on the gstreamer plugin or any other plugin, otherwise we will
>> have to fix them all afterwards.
>
> This is not gonna work out. You have to deal with API and ABI breakage
> if you are working outside the tree and wanna be closed source. That is
> the price you pay. I don't see any other way around that.
>
> Remember that a lot of things are highly related to the Bluetooth
> specification and A2DP is changing quickly. Actually the versions 1.4
> are already on their way to be getting approved at some point. Also the
> meta data transfer needs some extra love.
I 100% agree with that too. Maybe we just misundertood ourselves about
how "public" it should bet :-)
Basically what i meant is that we should define & stabilize this API for
our own internal use (Gst, ALSA, PulseAudio), and for other people
involved in the Bluez project working also on some out of tree project
(that would be me and maybe the Access guys AFAIK)
However i'm fully aware that this API will break from time to time due
to changes or new features, and won't blame anybody for that :-)
>
> And we need a security audit before ever thinking about making this
> really public and stabilize it.
Well, i didn't mean something *that* public (at least not for now).
I just meant something not-completely-unstable-not-documented-that-
will-keep-changing-and-breaking-my-software-for-no-reason. :-)
So this looks that we agree on everything afterall. :-)
> The LGPL wish is easy to solve. Get Johan and Luiz to agree here on the
> mailing list and then we make ipc.h and an upcoming ipc.c licensed under
> LGPL and then you can copy it out from the bluez-utils source and use
> it.
I was more thinking of as a complete rewrite of ipc.h (we should find it
another name btw : lets call it newipc.h for now ;-) ).
I already started thinking to how i would like to see it look.
It should be relatively lightweight, expose directly a message based API
(as you would find on most RTOS), with just a few functions to create
and free a session to the audio daemon, and to retrieve the data socket,
so that each user wouldn't have to know the tricks about ancilliary data
passing :-)
I fact it should be so lightweight that i think we could static inline
all the functions, and thus we wouldn't even need a *.c file.
I'm waiting for comments, int the meantime i'm gonna start drafting a
newipc.h :-)
Cheers,
Fabien
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Fabien,
> Well, *I do* care.
> As i told you back in Montpellier, i need a way to plug an external
> (proprietary) hardware accelerated audio system onto the audio service.
> In fact i could start working on such a library right away, provided
> that it is LGPL, so that i can link a proprietary stuff on top of it.
> Even if it is not packaged as an external library at first, provided i
> can somehow copy the code out of bluez tree and rebuild a LGPL library
> out of it would be acceptable as a first step. :-)
I am okay with that. That is not the problem. Having that code under
LGPL license is no big deal for me. I am actually fully okay with that.
However please remember that my default license will always be GPL and
you really have to tell me if you want something different.
> If that can't be done then i'm gonna go grumble in a corner and we will
> have missed an opportunity to move the bluez audio system forward. :-(
> And remembering what Marcel told us during the meeting, the IPC API is
> not public because "we don't really know what we're doing".
> My answer to that is:
> - having worked on audio stuff for some time now, i think i know what
> i would be doing if i was to work on this API : which mean it would be
> made stable pretty quickly.
> - We'd better start stabilizing the API before too much effort has
> been put on the gstreamer plugin or any other plugin, otherwise we will
> have to fix them all afterwards.
This is not gonna work out. You have to deal with API and ABI breakage
if you are working outside the tree and wanna be closed source. That is
the price you pay. I don't see any other way around that.
Remember that a lot of things are highly related to the Bluetooth
specification and A2DP is changing quickly. Actually the versions 1.4
are already on their way to be getting approved at some point. Also the
meta data transfer needs some extra love.
And we need a security audit before ever thinking about making this
really public and stabilize it.
> A last thing : this is likely to be a one time offer, because i need to
> start working on this stuff as soon as today. If we miss the window i
> won't be able to spent company time on this library, which mean i will
> only be able to get involved on my spare time, which i kind of lack
> these days...
The LGPL wish is easy to solve. Get Johan and Luiz to agree here on the
mailing list and then we make ipc.h and an upcoming ipc.c licensed under
LGPL and then you can copy it out from the bluez-utils source and use
it. Just a warning up front. You have to wrap it into a library by
yourself, because otherwise you might be violating the LGPL.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hey
I asked Marcel the same thing a while back.
It would make sense to factor the common stuff into unix.c or create
an ipc.c for that. We can link these to each plugin without messing
around with libraries.
Brad
On 10/8/07, Marcel Holtmann <[email protected]> wrote:
> Hi Luiz,
>
> > I guess we really need a tiny library for ipc, we dont want to
> > duplicate code from
> > pcm_bluetooth.c again in a2dpsink, it might happen that someone need this
> > in another plugin or so.
>
> no no and no. I don't care what other plugins (outside bluez-utils) need
> and want at the moment. It is perfectly fine to link an object file more
> than once. That must be enough and a library in the end is nothing
> different.
>
> Regards
>
> Marcel
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Luiz,
> I guess we really need a tiny library for ipc, we dont want to
> duplicate code from
> pcm_bluetooth.c again in a2dpsink, it might happen that someone need this
> in another plugin or so.
no no and no. I don't care what other plugins (outside bluez-utils) need
and want at the moment. It is perfectly fine to link an object file more
than once. That must be enough and a library in the end is nothing
different.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi thiago,
I guess we really need a tiny library for ipc, we dont want to
duplicate code from
pcm_bluetooth.c again in a2dpsink, it might happen that someone need this
in another plugin or so.
-- =
Luiz Augusto von Dentz
Engenheiro de Computa=E7=E3o
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
This patch adds the prerolling to the gsta2dpsink gstreamer plugin, it sends
the configuration packet to the device and prepares the connection.
It is currently only supporting sbc, needs to be extended to mp3.
This patch includes the full set of changes the previous one did.
I'll be waiting comments, reviews or sugestions.
BR,
Thiago
On 10/1/07, thiagoss <[email protected]> wrote:
>
> GstA2dpSink was extending GstAudioSink, but there is a problem in that,
> GstAudioSink expects only
> "audio/x-raw-int", "audio/x-raw-float", "audio/x-mulaw" or "audio/x-alaw"
> as media types. GstA2dpSink should support mp3 and sbc, that's causing a
> runtime error. This patch changes the base class from GstAudioSink to
> GstBaseSink, changing the stub functions to be implemented also.
>
>
> Best regards,
>
>
> Thiago
>
>