[Bluez-devel] question about hci_usb endpoint selection...

[Bluez-devel] question about hci_usb endpoint selection...

[Lars Grunewaldt]

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

Hi there,

I already asked this before, but I want to "nail down" this problem now,
so I'm asking again and hope that someone can give some suggestions that
even my stupid brain can understand. If this is the wrong list to ask,
just point me to the correct one, and I'll post again there.

The problem is this:
when using sco and using different voice modes (0x0060 for 16bit/8kHz,
0x0040 for 8bit/8kHz), different "alternate settings" have to be used on
hci_usb.

The former answer was:
"Don't use this patch [changing the "alternate settings" selection
hardcodedly] and accept the default voice setting of 0x0060."

We really don't want to. There are MANY people out there who want to use
16 bit audio, and MANY who want to use 8bit MU_LAW. What has to be done
to make it possible to change this "alternate setting" when we actually
*need* not alternate setting "2" (16bit), but use alternate setting "1"
when needed?

Marcel pointed out that:
"You can make use of the notify() callback and adjust the alternate
setting as needed. Maybe you have to unlink and re-submit the ISOC
URB's, but the best way is to start the ISOC URB's only when a SCO
connection is created."

Uhm, sorry. What? Yes, I'm not firm in kernel hacking, yes, I did not
RTFM, please just push me into the right direction here. Either API
documentation href and/or "use this and that function", or just dump
some lines of pseudo code with "what function comes from what API" so
that I can get a basic understanding what's going on in hci_usb. What
notify callback? How to register? Where can I find an example of someone
else doing this? Where can I find out what an ISOC URB really is?

I really don't want someone else to do my work, I just don't know where
to begin :'(

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

iD8DBQFBbSOlQWC6DTWkDAoRAvCeAJ0dVdrxZQLICG+YWblj66AV13L2CQCfUy0t
Ik0eK8//nhu6vUssynVgT74=
=+L+B
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] question about hci_usb endpoint selection...

[Marcel Holtmann]

Hi Lars,

> I already asked this before, but I want to "nail down" this problem now,
> so I'm asking again and hope that someone can give some suggestions that
> even my stupid brain can understand. If this is the wrong list to ask,
> just point me to the correct one, and I'll post again there.
> 
> The problem is this:
> when using sco and using different voice modes (0x0060 for 16bit/8kHz,
> 0x0040 for 8bit/8kHz), different "alternate settings" have to be used on
> hci_usb.
> 
> The former answer was:
> "Don't use this patch [changing the "alternate settings" selection
> hardcodedly] and accept the default voice setting of 0x0060."
> 
> We really don't want to. There are MANY people out there who want to use
> 16 bit audio, and MANY who want to use 8bit MU_LAW. What has to be done
> to make it possible to change this "alternate setting" when we actually
> *need* not alternate setting "2" (16bit), but use alternate setting "1"
> when needed?
> 
> Marcel pointed out that:
> "You can make use of the notify() callback and adjust the alternate
> setting as needed. Maybe you have to unlink and re-submit the ISOC
> URB's, but the best way is to start the ISOC URB's only when a SCO
> connection is created."
> 
> Uhm, sorry. What? Yes, I'm not firm in kernel hacking, yes, I did not
> RTFM, please just push me into the right direction here. Either API
> documentation href and/or "use this and that function", or just dump
> some lines of pseudo code with "what function comes from what API" so
> that I can get a basic understanding what's going on in hci_usb. What
> notify callback? How to register? Where can I find an example of someone
> else doing this? Where can I find out what an ISOC URB really is?

look at the hci_usb driver and add the notify() callback function for
it. This function gets called when you change the voice setting or a new
connection is added or removed. I changed the connection hash to count
the ACL and SCO links separatly and disabled the tasklet when calling
this function so that the core stops processing TX packets and enable it
after the driver finished anything it has to do.

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] question about hci_usb endpoint selection...

[Lars Grunewaldt]

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

Marcel Holtmann wrote:

| look at the hci_usb driver and add the notify() callback function for
| it. This function gets called when you change the voice setting or a new
| connection is added or removed. I changed the connection hash to count
| the ACL and SCO links separatly and disabled the tasklet when calling
| this function so that the core stops processing TX packets and enable it
| after the driver finished anything it has to do.

Hi there,

OK, I added hci_usb_notify(..) and it works as it should (get's the
notify when voice mode is changed).

Now for the "real stuff"... :)

I think to handle the voice mode change correctly, I have to duplicate
the code from about line 874..922 that locates the "proper" alternate
setting; before this can happen, the notify function must close

((husb *)hdev->driver_data)->isoc_iface with
usb_driver_release_interface(...)

is there anything else to do? Must some buffers be dropped or free'd or
something? is it possible to simply re-set
isoc_iface, isoc_in_ep and isoc_out_ep?

Or is it in fact not neccesary to disconnect isoc_iface and only change
the values of isoc_in_ep and isoc_out_ep?

I don't know much about the usb internals, so I ask the list again.

Thanks very much for bringing this topic forward :))

cu,
~  Lars

PS: one last question, I'm using kernel 2.6.8.1 now and hci_usb.c uses
CONFIG_BT_HCIUSB_DEBUG to enable/disable debugging; my kernel config
says this option does not exists, so, how to enable debugging properly?
Or is just the option accidently missing from kernel config in this release?

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

iD8DBQFBbvSwQWC6DTWkDAoRArROAJ9ita8X+pxnxEDeH6f2iU4JUbMsDACfbao5
F0MQVzgEB8guoBDKw/McCbU=
=iJew
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] question about hci_usb endpoint selection...

[Marcel Holtmann]

Hi Lars,

> OK, I added hci_usb_notify(..) and it works as it should (get's the
> notify when voice mode is changed).

you also need some extra changes from my Bitkeeper repository, because I
fixed some locking parts around the notify framework. The number of ACL
and SCO links are now also counted separately. You need that for
selecting the correct alternate setting.

> Now for the "real stuff"... :)
> 
> I think to handle the voice mode change correctly, I have to duplicate
> the code from about line 874..922 that locates the "proper" alternate
> setting; before this can happen, the notify function must close

No, because the correct alternate setting is described in the Bluetooth
HCI USB transport specification.

> ((husb *)hdev->driver_data)->isoc_iface with
> usb_driver_release_interface(...)

Don't try to release and claim it again. You are not in the probe()
function.

> is there anything else to do? Must some buffers be dropped or free'd or
> something? is it possible to simply re-set
> isoc_iface, isoc_in_ep and isoc_out_ep?

No simple reset. Change the alternate setting, but you maybe have to
suspend the ISOC URBs first and then resume them. Check the USB API
definition of it first.

> Or is it in fact not neccesary to disconnect isoc_iface and only change
> the values of isoc_in_ep and isoc_out_ep?

Maybe you should look at the /proc/bus/usb/devices first, because the
endpoint identifiers on the second interface are always the same. You
must tell the USB core to switch the alternate setting.

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] question about hci_usb endpoint selection...

[Lars Grunewaldt]

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

Hi Marcel,

Marcel Holtmann wrote:
|>OK, I added hci_usb_notify(..) and it works as it should (get's the
|>notify when voice mode is changed).
|
| you also need some extra changes from my Bitkeeper repository, because I
| fixed some locking parts around the notify framework. The number of ACL
| and SCO links are now also counted separately. You need that for
| selecting the correct alternate setting.

Can you please describe how I can access your Bitkeeper repository? I
never used Bitkeeper before, and I'd rather not because of it's strange
license issues and stuff. Will this changes be in the MH-patches
sometime soon? Right now I'm trying to understand how things work, and I
think it'll be at least one more week until I can modprobe something
that might work, so I can wait a bit for a next release. Of course, if
you don't plan to release patches containing this changes soon, I'll use
Bitkeeper.

|>is there anything else to do? Must some buffers be dropped or free'd or
|>something? is it possible to simply re-set
|>isoc_iface, isoc_in_ep and isoc_out_ep?
|
|
| No simple reset. Change the alternate setting, but you maybe have to
| suspend the ISOC URBs first and then resume them. Check the USB API
| definition of it first.

OK, after digging for an USB API documentation I found:

***
~ int usb_set_interface(struct usb_device *dev, int interface, int
alternate);
***

The documentation/manpage says:

***
Note that in the Linux USB subsystem, bandwidth associated with an
endpoint in a given alternate setting is not reserved until an URB is
submitted that needs that bandwidth. Some other operating systems
allocate bandwidth early, when a configuration is chosen.

This call is synchronous, and may not be used in an interrupt context.
Also, drivers must not change altsettings while urbs are scheduled for
endpoints in that interface; all such urbs must first be completed
(perhaps forced by unlinking).
***

Questions I'm unable to answer myself right now:

1. are we in an interrupt context? (don't think so)
2. how can we make sure that there are no pending urbs? maybe we have to
change the setting asynchronus in the transmit function or something? Or
should we unlink pending SCO URBs?
3. can we safely assume that the endpoint ID's that are stored in
isoc_in_ep and isoc_out_ep are always the same for different alternate
settings?
4. I think we *can* assume that alternate setting 1 matches for 0x0?40
voice modes, while alternate setting 2 matches for 0x0?60 voice modes,
as you (Marcel) wrote that it's defined in the BT-USB-HCI specs.
5. Why do I need the SCO link count? Shouldn't it be sufficient to call

usb_set_interface(hcidev->udev, hcidev->isoc_iface,NEW_ALTERNATE_SETTING);

after making sure that we solved the URB release problem?

thanks for helping me out so much :)
~  Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBcUn9QWC6DTWkDAoRAipKAJ4mfV/4SjYOtf3sDmCk+Y+X/gAPmQCgr8PS
qd4BK7v0u2ZBiULDQ24PB6k=
=0vo5
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] question about hci_usb endpoint selection...

[Marcel Holtmann]

Hi Lars,

> Can you please describe how I can access your Bitkeeper repository? I
> never used Bitkeeper before, and I'd rather not because of it's strange
> license issues and stuff. Will this changes be in the MH-patches
> sometime soon? Right now I'm trying to understand how things work, and I
> think it'll be at least one more week until I can modprobe something
> that might work, so I can wait a bit for a next release. Of course, if
> you don't plan to release patches containing this changes soon, I'll use
> Bitkeeper.

I am waiting for the final 2.6.9 release before I put out my next -mh
patch. So it should be very soon. Otherwise check the Bitkeeper docs in
the kernel source.

> OK, after digging for an USB API documentation I found:
> 
> ***
> ~ int usb_set_interface(struct usb_device *dev, int interface, int
> alternate);
> ***
> 
> The documentation/manpage says:
> 
> ***
> Note that in the Linux USB subsystem, bandwidth associated with an
> endpoint in a given alternate setting is not reserved until an URB is
> submitted that needs that bandwidth. Some other operating systems
> allocate bandwidth early, when a configuration is chosen.
> 
> This call is synchronous, and may not be used in an interrupt context.
> Also, drivers must not change altsettings while urbs are scheduled for
> endpoints in that interface; all such urbs must first be completed
> (perhaps forced by unlinking).
> ***
> 
> Questions I'm unable to answer myself right now:
> 
> 1. are we in an interrupt context? (don't think so)

You can check this with in_interrupt() and I think we are in interrupt
context when notify() is called.

> 2. how can we make sure that there are no pending urbs? maybe we have to
> change the setting asynchronus in the transmit function or something? Or
> should we unlink pending SCO URBs?

I think you can't. We have to unlink them and resubmit them, but I don't
know this for sure.

> 3. can we safely assume that the endpoint ID's that are stored in
> isoc_in_ep and isoc_out_ep are always the same for different alternate
> settings?

Check the HCI USB specification. I think it talks very clear how
endpoint IDs must be numbered.

> 4. I think we *can* assume that alternate setting 1 matches for 0x0?40
> voice modes, while alternate setting 2 matches for 0x0?60 voice modes,
> as you (Marcel) wrote that it's defined in the BT-USB-HCI specs.

That is not the whole truth. It also depends on the number of SCO
connections.

> 5. Why do I need the SCO link count? Shouldn't it be sufficient to call
> 
> usb_set_interface(hcidev->udev, hcidev->isoc_iface,NEW_ALTERNATE_SETTING);
> 
> after making sure that we solved the URB release problem?

Look at the specification. The number of SCO connection and the current
voice setting defines the alternate setting.

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] question about hci_usb endpoint selection...

[Lars Grunewaldt]

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

Hi Marcel,

Marcel Holtmann wrote:
| Hi Lars,
|
| I am waiting for the final 2.6.9 release before I put out my next -mh
| patch. So it should be very soon. Otherwise check the Bitkeeper docs in
| the kernel source.

OK, I'll watch it. If I need to get into it before you released, I'll
use Bitkeeper.

|>OK, after digging for an USB API documentation I found:
|>
|>***
|>~ int usb_set_interface(struct usb_device *dev, int interface, int
|>alternate);
|>***
|>
|>The documentation/manpage says:
|>
|>***
|>Note that in the Linux USB subsystem, bandwidth associated with an
|>endpoint in a given alternate setting is not reserved until an URB is
|>submitted that needs that bandwidth. Some other operating systems
|>allocate bandwidth early, when a configuration is chosen.
|>
|>This call is synchronous, and may not be used in an interrupt context.
|>Also, drivers must not change altsettings while urbs are scheduled for
|>endpoints in that interface; all such urbs must first be completed
|>(perhaps forced by unlinking).
|>***
|>
|>Questions I'm unable to answer myself right now:
|>
|>1. are we in an interrupt context? (don't think so)
|
|
| You can check this with in_interrupt() and I think we are in interrupt
| context when notify() is called.

OK, I'll check. This is bad, because we can't use usb_set_interface
directly in the notify() function. Do you have an idea how we can solve
this? I still don't understand the structure of hci_usb well enough, but
I'm improving :)

We should be able to "mark" the change and do the switch somewhere else,
but...? This is kind of new stuff for me, but I'm eager to learn. Maybe
I should get this book about linux kernel programming...

|>2. how can we make sure that there are no pending urbs? maybe we have to
|>change the setting asynchronus in the transmit function or something? Or
|>should we unlink pending SCO URBs?
|
|
| I think you can't. We have to unlink them and resubmit them, but I don't
| know this for sure.

Looking at the docs, I think we have to unlink and resubmit them. Thing
is, if we can't call usb_set_interface from within notify() anyway,
maybe there's a nice workaround for both problems by doing it in the
tx/rx handlers or something?

|>3. can we safely assume that the endpoint ID's that are stored in
|>isoc_in_ep and isoc_out_ep are always the same for different alternate
|>settings?
|
| Check the HCI USB specification. I think it talks very clear how
| endpoint IDs must be numbered.

Will do so.

|>4. I think we *can* assume that alternate setting 1 matches for 0x0?40
|>voice modes, while alternate setting 2 matches for 0x0?60 voice modes,
|>as you (Marcel) wrote that it's defined in the BT-USB-HCI specs.
|
|
| Look at the specification. The number of SCO connection and the current
| voice setting defines the alternate setting.

Aaaah I see! Thanks for beeing patient with me :)

I won't have time until monday, but I'll jump into the doc's again I think.

I maybe writing me students final work (bacheloer) about proper
implementing alsa/bt/sco, so it's possible that I'll invest very much
time into this in the next few month. Nothing for sure though, yet.

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

iD8DBQFBcn5wQWC6DTWkDAoRAr2SAJ0UIDX8ZGbHFxhvxxLkpr1J8KnS4QCgtzcY
TxGFJnkeen/0H88PzwMIVNc=
=R+Qk
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel