[Bluez-devel] BlueZ and the ALSA support

[Bluez-devel] BlueZ and the ALSA support

[Marcel Holtmann]

Hi Folks,

I spent some hours to clean up the btsco CVS repository from the ALSA
Bluetooth project and also changed the code a little bit for easier use
by non technical people. It should now compile and work without the need
of reinstalling or changing any ALSA stuff. Here is a quick walktrough.

First the CVS repository must be checked out:

	cvs -d:pserver:anonymous@cvs.sf.net:/cvsroot/bluetooth-alsa login
	cvs -d:pserver:anonymous@cvs.sf.net:/cvsroot/bluetooth-alsa co btsco

After that is must be compiled:

	./bootstrap
	./configure
	make
	make install
	make maintainer-clean

And you need the kernel module:

	cd kernel
	make
	make install
	make clean

Now go ahead and use it like before.

As you may now realized the snd-bt-sco kernel driver is also inside this
repository and with a recent 2.6 kernel there are no problems with
compiling a kernel module outside the kernel source directory. However
if you haven't installed the running kernel by yourself you may need to
install the kernel source package from your distribution.

Every crappy header file is now removed and the needed IOCTL and the
HWDEP definition is added to the source directly in a compatible way.

The A2DP related programs are integrated into the Makefile and they are
also compiled, but for now they are not installed.

This should make the development a lot more easier :)

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] BlueZ and the ALSA support

[Lars Grunewaldt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

this is great news, thanks a lot!

I would have gone through the code sooner or later myself, I think I
could have managed it because I have a little kernel experience but I'm
pretty sure you are much more competent and were able to do it in a
fraction of the time :)

Maybe I'll be able to put some efforts into this project when I'm doing
my final exams "practical part" (what's "Diplomarbeit" called in
english? :) - so it could be possible that snd-bt-sco might get a
full-time coder for about three month :)

I'll be asking many questions, but it should be worth the effort :)

Anyway, thanks again for cleaning up the code for us (or everyone).

I'll check it out as soon as possible (maybe next week).

regards,
~  Lars

Marcel Holtmann wrote:
| Hi Folks,
|
| I spent some hours to clean up the btsco CVS repository from the ALSA
| Bluetooth project and also changed the code a little bit for easier use
| by non technical people. It should now compile and work without the need
| of reinstalling or changing any ALSA stuff. Here is a quick walktrough.
|
| First the CVS repository must be checked out:
|
| 	cvs -d:pserver:anonymous@cvs.sf.net:/cvsroot/bluetooth-alsa login
| 	cvs -d:pserver:anonymous@cvs.sf.net:/cvsroot/bluetooth-alsa co btsco
|
| After that is must be compiled:
|
| 	./bootstrap
| 	./configure
| 	make
| 	make install
| 	make maintainer-clean
|
| And you need the kernel module:
|
| 	cd kernel
| 	make
| 	make install
| 	make clean
|
| Now go ahead and use it like before.
|
| As you may now realized the snd-bt-sco kernel driver is also inside this
| repository and with a recent 2.6 kernel there are no problems with
| compiling a kernel module outside the kernel source directory. However
| if you haven't installed the running kernel by yourself you may need to
| install the kernel source package from your distribution.
|
| Every crappy header file is now removed and the needed IOCTL and the
| HWDEP definition is added to the source directly in a compatible way.
|
| The A2DP related programs are integrated into the Makefile and they are
| also compiled, but for now they are not installed.
|
| This should make the development a lot more easier :)
|
| Regards
|
| Marcel
|
|
|
|
| -------------------------------------------------------
| This SF.Net email is sponsored by: InterSystems CACHE
| FREE OODBMS DOWNLOAD - A multidimensional database that combines
| robust object and relational technologies, making it a perfect match
| for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
| _______________________________________________
| Bluez-devel mailing list
| Bluez-devel@lists.sourceforge.net
| https://lists.sourceforge.net/lists/listinfo/bluez-devel
|

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBn/kBQWC6DTWkDAoRAnV9AKCF2V7wQcDsnSedthm/nLOJuokYNACghI/J
eS6B9cxs9R9MgXwPIHRxjTU=
=DkVP
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] BlueZ and the ALSA support

[Brad Midgley]

Marcel,

Wow. All that stuff was on my to-do list.

Do we owe you one beer, a six-pack or a whole case? :)

Brad

Marcel Holtmann wrote:
> Hi Folks,
> 
> I spent some hours to clean up the btsco CVS repository from the ALSA
> Bluetooth project and also changed the code a little bit for easier use
> by non technical people. It should now compile and work without the need
> of reinstalling or changing any ALSA stuff. Here is a quick walktrough.
> 
> First the CVS repository must be checked out:
> 
> 	cvs -d:pserver:anonymous@cvs.sf.net:/cvsroot/bluetooth-alsa login
> 	cvs -d:pserver:anonymous@cvs.sf.net:/cvsroot/bluetooth-alsa co btsco
> 
> After that is must be compiled:
> 
> 	./bootstrap
> 	./configure
> 	make
> 	make install
> 	make maintainer-clean
> 
> And you need the kernel module:
> 
> 	cd kernel
> 	make
> 	make install
> 	make clean
> 
> Now go ahead and use it like before.
> 
> As you may now realized the snd-bt-sco kernel driver is also inside this
> repository and with a recent 2.6 kernel there are no problems with
> compiling a kernel module outside the kernel source directory. However
> if you haven't installed the running kernel by yourself you may need to
> install the kernel source package from your distribution.
> 
> Every crappy header file is now removed and the needed IOCTL and the
> HWDEP definition is added to the source directly in a compatible way.
> 
> The A2DP related programs are integrated into the Makefile and they are
> also compiled, but for now they are not installed.
> 
> This should make the development a lot more easier :)
> 
> Regards
> 
> Marcel
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: InterSystems CACHE
> FREE OODBMS DOWNLOAD - A multidimensional database that combines
> robust object and relational technologies, making it a perfect match
> for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] BlueZ and the ALSA support

[Marcel Holtmann]

Hi Brad,

> Wow. All that stuff was on my to-do list.

I am sorry for shrinking your todo list, but this can happen if you give
me access to your CVS ;)

> Do we owe you one beer, a six-pack or a whole case? :)

Actually I really knew what to do, because I spent so many days in
getting the BlueZ CVS in a good shape that this was a really easy job
for me. Once you got the understanding for autoconf/automake, things
will get really simple. However I will maybe ping you about the beer
idea at some time ;)

Seriously, I saw that you also updated the web page. This is great and
it would be also great if you can fill in the README with some infos
about it.

Do anyone mind if we start using the kernel coding style? It will make
later integration into the kernel or BlueZ so much easier.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] BlueZ and the ALSA support

[Lars Grunewaldt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marcel Holtmann wrote:
| Actually I really knew what to do, because I spent so many days in
| getting the BlueZ CVS in a good shape that this was a really easy job
| for me. Once you got the understanding for autoconf/automake, things
| will get really simple. However I will maybe ping you about the beer
| idea at some time ;)

for a starter:

(|~|
~ {_}

Just a pint, though... ;)

| Do anyone mind if we start using the kernel coding style? It will make
| later integration into the kernel or BlueZ so much easier.

I definitly won't mind, we'll have to migrate anyway, and sooner is
better than later.

My problem how to change the usb_hci endpoint without killing the n.y.t.
urbs is still pending, did you have any new ideas on this?

Help appreciated.

regards,
~  Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBoNNLQWC6DTWkDAoRAj55AKCTgZl1yflsYLRHrDyXsj85ULtRgQCguZV4
VPzW4427QTB4slb1Ulpxwtg=
=RCpm
-----END PGP SIGNATURE-----


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] BlueZ and the ALSA support

[Marcel Holtmann]

Hi Lars,

> | Do anyone mind if we start using the kernel coding style? It will make
> | later integration into the kernel or BlueZ so much easier.
> 
> I definitly won't mind, we'll have to migrate anyway, and sooner is
> better than later.

this is correct, but I won't integrate the current idea of the btsco
kernel module. In the end it must work without the SCO socket in between
for sending and receiving the SCO data packets from the HCI. And I like
to have the eSCO support also. However even I don't have the right test
hardware for that.

> My problem how to change the usb_hci endpoint without killing the n.y.t.
> urbs is still pending, did you have any new ideas on this?

My problem is that I haven't written all of the hci_usb driver code and
some parts are still so messy that I think a complete rewrite is the
best that we can do. But what I will do is to add a module parameter for
choosing the alternate setting that can be changed at runtime. To bring
up a device with a new alternate setting you only have to unplug and
then plug it in again. This is not the solution we should have, but it
will help us with testing the SCO stuff without recompiling the kernel
every time.

Regards

Marcel




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] BlueZ and the ALSA support

[Lars Grunewaldt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marcel Holtmann wrote:
| Hi Lars,
|
|
|>| Do anyone mind if we start using the kernel coding style? It will make
|>| later integration into the kernel or BlueZ so much easier.
|>
|>I definitly won't mind, we'll have to migrate anyway, and sooner is
|>better than later.
|
|
| this is correct, but I won't integrate the current idea of the btsco
| kernel module. In the end it must work without the SCO socket in between
| for sending and receiving the SCO data packets from the HCI. And I like
| to have the eSCO support also. However even I don't have the right test
| hardware for that.

Yes, you already mentioned that before. Depending on the time I'll have
to implement it, it won't be much of a problem to do a complete redesign
of the stuff. As soon as I understand what we'll need... ;)


|>My problem how to change the usb_hci endpoint without killing the n.y.t.
|>urbs is still pending, did you have any new ideas on this?
|
|
| My problem is that I haven't written all of the hci_usb driver code and
| some parts are still so messy that I think a complete rewrite is the
| best that we can do.

I see, did not know that.

| But what I will do is to add a module parameter for
| choosing the alternate setting that can be changed at runtime. To bring
| up a device with a new alternate setting you only have to unplug and
| then plug it in again. This is not the solution we should have, but it
| will help us with testing the SCO stuff without recompiling the kernel
| every time.

Yes, that would be a first step.

I hope I can have a look at the way how usb_hci works, so that I can
understand when an asynchronus/delayed change of the endpoint selection
could happen - or how we could get rid of not-send urbs. *sigh* just
need more time...

don't you think it should be possible to
a) block the submit of new urbs when a change notify has arrived
b) queue until the queue is empty
c) change the endpoint setting and release the block

I don't know to which bad runs or locks this could lead...

cu,
~  Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBoPbzQWC6DTWkDAoRAhDvAJ9OiAlvi1fjivMFchnmb4ehBe53hwCfey+1
UEARQw9ddXYRhewZvKFf014=
=kTD6
-----END PGP SIGNATURE-----


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] BlueZ and the ALSA support

[Marcel Holtmann]

Hi Lars,

> | My problem is that I haven't written all of the hci_usb driver code and
> | some parts are still so messy that I think a complete rewrite is the
> | best that we can do.
> 
> I see, did not know that.

we use our own URB management and this is bad and ugly :(

> | But what I will do is to add a module parameter for
> | choosing the alternate setting that can be changed at runtime. To bring
> | up a device with a new alternate setting you only have to unplug and
> | then plug it in again. This is not the solution we should have, but it
> | will help us with testing the SCO stuff without recompiling the kernel
> | every time.
> 
> Yes, that would be a first step.

Maybe I get this done tomorrow.

> I hope I can have a look at the way how usb_hci works, so that I can
> understand when an asynchronus/delayed change of the endpoint selection
> could happen - or how we could get rid of not-send urbs. *sigh* just
> need more time...
> 
> don't you think it should be possible to
> a) block the submit of new urbs when a change notify has arrived
> b) queue until the queue is empty
> c) change the endpoint setting and release the block
> 
> I don't know to which bad runs or locks this could lead...

To be honest, I don't know. This ISOC stuff is still a mystery to me and
so far I don't know of any Linux driver that is using the ISOC transfers
and have to change the alternate setting at the same time. Selecting it
at probe() time is very easy.

Regards

Marcel




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] BlueZ and the ALSA support

[Lars Grunewaldt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marcel Holtmann wrote:
|>don't you think it should be possible to
|>a) block the submit of new urbs when a change notify has arrived
|>b) queue until the queue is empty
|>c) change the endpoint setting and release the block
|>
|>I don't know to which bad runs or locks this could lead...
|
|
| To be honest, I don't know. This ISOC stuff is still a mystery to me and
| so far I don't know of any Linux driver that is using the ISOC transfers
| and have to change the alternate setting at the same time. Selecting it
| at probe() time is very easy.


Maybe we simply have to try what happens *shudder*... any ideas whom we
could ask for more information? linux usb devlist?

cu,
~  Lars

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBoRJ1QWC6DTWkDAoRAnonAKCur76BoMJjdiW1C1Hr4+1UNXStgQCeNQR9
+PjiFwiOMa8LrOTjDE0/xMw=
=f1x7
-----END PGP SIGNATURE-----


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] BlueZ and the ALSA support

[Marcel Holtmann]

Hi Lars,

> | To be honest, I don't know. This ISOC stuff is still a mystery to me and
> | so far I don't know of any Linux driver that is using the ISOC transfers
> | and have to change the alternate setting at the same time. Selecting it
> | at probe() time is very easy.

> Maybe we simply have to try what happens *shudder*... any ideas whom we
> could ask for more information? linux usb devlist?

when you try, expect kernel freezes or crashes. The only place to ask is
the Linux USB developer mailing list, but I think we should first clean
up our URB management mess.

Regards

Marcel




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] BlueZ and the ALSA support

[Lars Grunewaldt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marcel Holtmann wrote:

|
|>Maybe we simply have to try what happens *shudder*... any ideas whom we
|>could ask for more information? linux usb devlist?
|
|
| when you try, expect kernel freezes or crashes. The only place to ask is
| the Linux USB developer mailing list, but I think we should first clean
| up our URB management mess.
|

Could be a good idea.

Maybe you could point out a document or write a short description what's
going on right now, and how it should be solved correctly? Would help a
lot to know what exists and where we should head to - if you already
know, that is. If not, the status quo would be interesting none the
less, from a logical point of view, not the code.

regards,
~  Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBoR3aQWC6DTWkDAoRAuGmAJ0dNDmjdu0p0ouyJtuaHJbKwsXqBwCgoR6S
yhoEfK49TZAkC4PHG3pU8cc=
=CPm5
-----END PGP SIGNATURE-----


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] BlueZ and the ALSA support

[Brad Midgley]

Marcel

> Do anyone mind if we start using the kernel coding style? It will make
> later integration into the kernel or BlueZ so much easier.

I read up on the guidelines after you asked about this last time. I just 
need to tweak .emacs to stick to 8-space tabbing and I can use the 
kernel guidelines.

I will reindent everything using that script in the kernel as long as no 
one is hanging onto changes that will get merge conflicts.

Brad


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] BlueZ and the ALSA support

[Marcel Holtmann]

Hi Brad,

> > Do anyone mind if we start using the kernel coding style? It will make
> > later integration into the kernel or BlueZ so much easier.
> 
> I read up on the guidelines after you asked about this last time. I just 
> need to tweak .emacs to stick to 8-space tabbing and I can use the 
> kernel guidelines.
> 
> I will reindent everything using that script in the kernel as long as no 
> one is hanging onto changes that will get merge conflicts.

please do so now. The tabbing change will be the biggest one and I have
no uncommitted changes at the moment.

Regards

Marcel




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] BlueZ and the ALSA support

[Brad Midgley]

Marcel,

I reindented a2play.c and both btsco.c files.

I promise to get emacs to behave. I will also remove the typedefs in 
a2play.c.

Brad

Marcel Holtmann wrote:
> Hi Brad,
> 
> 
>>>Do anyone mind if we start using the kernel coding style? It will make
>>>later integration into the kernel or BlueZ so much easier.
>>
>>I read up on the guidelines after you asked about this last time. I just 
>>need to tweak .emacs to stick to 8-space tabbing and I can use the 
>>kernel guidelines.
>>
>>I will reindent everything using that script in the kernel as long as no 
>>one is hanging onto changes that will get merge conflicts.
> 
> 
> please do so now. The tabbing change will be the biggest one and I have
> no uncommitted changes at the moment.
> 
> Regards
> 
> Marcel
> 
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel