* [Bluez-devel] Re: Bluetooth headset with Bluetooth usb dongle status. [not found] ` <3F1752C5.5020701@dsto.defence.gov.au> @ 2003-07-18 12:15 ` James Courtier-Dutton 2003-07-18 13:04 ` Marcel Holtmann 2003-07-21 23:49 ` Max Krasnyansky 0 siblings, 2 replies; 12+ messages in thread From: James Courtier-Dutton @ 2003-07-18 12:15 UTC (permalink / raw) To: bluez Dev I would like to discuss possible changes in the sco to hci-usb layer api. I would like people to agree the changes before I go ahead and code them. I don't have exact function names etc. yet, but just a general idea of what one needs to do in order to implement an alsa interface to bluez. There are a number of problems with the current usb-hci.c driver. I have a dirty fix for sound recording, but playback will need a lot of work. If you want recording to work, just put in a for loop round the "static int hci_usb_isoc_rx_submit(struct hci_usb *husb)" function to make it execute twice. See "e.g." below. It is a very dirty fix, because I don't think that everything gets freed when not in use, but at least it records sound at the correct speed. The playback problem is a scheduling problem. The "hci_usb_tx_complete" function uses the scheduler to kick off the next transmission, but the scheduler is too slow, and the correct method to use is getting the "hci_usb_tx_complete" function to retrieve the next packet to send from a ring buffer, and send it immeadiately during the "hci_usb_tx_complete" function. This is how the current usbaudio.c does it, so it proves that this method will work. So, I will need to implement a ring buffer. At the same time I want to implement sound output via alsa, so I want to make sure we have a good api to achieve that. alsa requires certain information from the sound card (ring buffer position etc.), and I will have to make sure that the information alsa needs in available, by maybe adding new api calls through the sco layer to the usb-hci.c layer. I think it would be a good idea to completely separate the isoc(sound) urb path from the int/bulk/control urb path. We also have the added complication that the alsa ring buffer is composed of just sound samples, but the sco layer converts that to packets with a header so the hci-usb.c layer has to deal with packets instead of samples. For 8 bit mono sound, SCO creates packets with 3 header bytes, and 24 sound samples. hci-usb.c then has to take each 27 byte packet and cut it down into 3 slices each 9 bytes in length. All packet sizes and slice sizes vary depending on 8/16 bits samples, and mono/stereo etc. So, there is going to be quite a lot of manipulation of the sound samples as they pass from alsa to the bluetooth device. The questions I am still trying to decide are: - 1) When should the conversion from alsa ring buffer to packets take place. So far the only workable solution I have come up with is that the "hci_usb_tx_complete" makes a callback all the way to the sco layer, and the sco layer grabs 24 bytes form the alsa ring buffer, adds it's header and returns from the callback. 2) interface to alsa. I think this should happen just above the SCO layer, but also ensuring that the SCO layer has enought api links with the hci-usb.c layer to be able to service all the alsa-driver api requirements. 3) Once that all works, modify the other low level hardware drivers to work with it. e.g. bluecard_cs.c etc. The final result will be: - 1) a small tool that will link a particular paired bluetooth device to a particular PCM device for alsa to work with. This tool will basically just take destination BTADDR and channel number to use, because alsa will have no knowledge of that sort of info. It will add a new sound card instance for each bluetooth device. 2) alsa will just think that the bluetooth headset is a normal soundcard. 3) This would make integration with current audio applications simple, because alsa supports the alsa-api as well as emulate the oss-api, so current audio applications would need no changes. 4) We could even implement headset "in the vicinity" detection, so that when the headset transitioned from out of range to in range, your computer could say hello! Cheers James e.g. static int hci_usb_isoc_rx_submit(struct hci_usb *husb) { struct _urb *_urb; struct urb *urb; int err, mtu, size; void *buf; int n; for(n=0;n<2;n++) { mtu = husb->isoc_in_ep->wMaxPacketSize; BT_INFO("isoc_rx_submit: mtu=%d", mtu); size = mtu * HCI_MAX_ISOC_FRAMES; buf = kmalloc(size, GFP_ATOMIC); if (!buf) return -ENOMEM; _urb = _urb_alloc(HCI_MAX_ISOC_FRAMES, GFP_ATOMIC); if (!_urb) { kfree(buf); return -ENOMEM; } _urb->type = HCI_SCODATA_PKT; _urb_queue_tail(__pending_q(husb, _urb->type), _urb); urb = &_urb->urb; urb->context = husb; urb->dev = husb->udev; urb->pipe = usb_rcvisocpipe(husb->udev, husb->isoc_in_ep->bEndpointAddress); urb->complete = hci_usb_rx_sync_complete; urb->transfer_buffer_length = size; urb->transfer_buffer = buf; urb->transfer_flags = USB_ISO_ASAP; __fill_isoc_desc(urb, size, mtu); BT_DBG("%s urb %p", husb->hdev.name, urb); err = usb_submit_urb(urb); if (err) { BT_ERR("%s isoc rx submit failed urb %p err %d", husb->hdev.name, urb, err); _urb_unlink(_urb); _urb_free(_urb); kfree(buf); } } /* End for loop */ return err; } #endif ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ Bluez-devel mailing list Bluez-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bluez-devel] Re: Bluetooth headset with Bluetooth usb dongle status. 2003-07-18 12:15 ` [Bluez-devel] Re: Bluetooth headset with Bluetooth usb dongle status James Courtier-Dutton @ 2003-07-18 13:04 ` Marcel Holtmann 2003-07-18 13:58 ` James Courtier-Dutton 2003-07-21 23:53 ` Max Krasnyansky 2003-07-21 23:49 ` Max Krasnyansky 1 sibling, 2 replies; 12+ messages in thread From: Marcel Holtmann @ 2003-07-18 13:04 UTC (permalink / raw) To: James Courtier-Dutton; +Cc: bluez Dev Hi James, > The playback problem is a scheduling problem. > The "hci_usb_tx_complete" function uses the scheduler to kick off the > next transmission, but the scheduler is too slow, and the correct method > to use is getting the "hci_usb_tx_complete" function to retrieve the > next packet to send from a ring buffer, and send it immeadiately during > the "hci_usb_tx_complete" function. This is how the current usbaudio.c > does it, so it proves that this method will work. > So, I will need to implement a ring buffer. > At the same time I want to implement sound output via alsa, so I want to > make sure we have a good api to achieve that. > alsa requires certain information from the sound card (ring buffer > position etc.), and I will have to make sure that the information alsa > needs in available, by maybe adding new api calls through the sco layer > to the usb-hci.c layer. I think it would be a good idea to completely > separate the isoc(sound) urb path from the int/bulk/control urb path. > We also have the added complication that the alsa ring buffer is > composed of just sound samples, but the sco layer converts that to > packets with a header so the hci-usb.c layer has to deal with packets > instead of samples. > For 8 bit mono sound, SCO creates packets with 3 header bytes, and 24 > sound samples. hci-usb.c then has to take each 27 byte packet and cut it > down into 3 slices each 9 bytes in length. All packet sizes and slice > sizes vary depending on 8/16 bits samples, and mono/stereo etc. the seperate handling of ISOC is a good idea. Max told me that ISOC URB's consumes USB bandwith and because of the fact that they are not needed all the time, we have to start and stop them dynamicly, if a SCO link is established or killed. My current idea of handling this is that the hci_usb driver checks for SCO links in connection complete and disconnect complete events. Another idea is to add another HCI driver method (for example hdev->notify), so that the HCI core can notify the driver of special events or errors. > So, there is going to be quite a lot of manipulation of the sound > samples as they pass from alsa to the bluetooth device. > The questions I am still trying to decide are: - > 1) When should the conversion from alsa ring buffer to packets take > place. So far the only workable solution I have come up with is that the > "hci_usb_tx_complete" makes a callback all the way to the sco layer, and > the sco layer grabs 24 bytes form the alsa ring buffer, adds it's header > and returns from the callback. > 2) interface to alsa. I think this should happen just above the SCO > layer, but also ensuring that the SCO layer has enought api links with > the hci-usb.c layer to be able to service all the alsa-driver api > requirements. > 3) Once that all works, modify the other low level hardware drivers to > work with it. e.g. bluecard_cs.c etc. The native integration of Bluetooth audio within Linux is one of the most wanted things. But we can't use ALSA for the 2.4 kernel, because it is not a part of the kernel. For the 2.6 this is no problem, but I also want to have support for OSS, because there will some people (like me) which still uses OSS. The integration of audio is not part of the Bluetooth drivers, because every Bluetooth HCI driver is only a transport driver which have to transport the HCI command, event, ACL and SCO data between the hardware and the HCI core layer. The SCO data would send from the HCI core through the hdev->send() callback and the driver can send the SCO data it gets from the hardware back with hci_recv_frame(). This means that all needed modifications for ALSA and OSS integration have to done in the HCI core or the SCO layer. And all other HCI drivers will still work with SCO like they do now. Regards Marcel ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ Bluez-devel mailing list Bluez-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bluez-devel] Re: Bluetooth headset with Bluetooth usb dongle status. 2003-07-18 13:04 ` Marcel Holtmann @ 2003-07-18 13:58 ` James Courtier-Dutton 2003-07-20 14:33 ` [Bluez-devel] " Jonathan Paisley 2003-07-22 0:18 ` [Bluez-devel] " Max Krasnyansky 2003-07-21 23:53 ` Max Krasnyansky 1 sibling, 2 replies; 12+ messages in thread From: James Courtier-Dutton @ 2003-07-18 13:58 UTC (permalink / raw) To: Marcel Holtmann; +Cc: bluez Dev Marcel Holtmann wrote: > Hi James, > > >>The playback problem is a scheduling problem. >>The "hci_usb_tx_complete" function uses the scheduler to kick off the >>next transmission, but the scheduler is too slow, and the correct method >>to use is getting the "hci_usb_tx_complete" function to retrieve the >>next packet to send from a ring buffer, and send it immeadiately during >>the "hci_usb_tx_complete" function. This is how the current usbaudio.c >>does it, so it proves that this method will work. >>So, I will need to implement a ring buffer. >>At the same time I want to implement sound output via alsa, so I want to >>make sure we have a good api to achieve that. >>alsa requires certain information from the sound card (ring buffer >>position etc.), and I will have to make sure that the information alsa >>needs in available, by maybe adding new api calls through the sco layer >>to the usb-hci.c layer. I think it would be a good idea to completely >>separate the isoc(sound) urb path from the int/bulk/control urb path. >>We also have the added complication that the alsa ring buffer is >>composed of just sound samples, but the sco layer converts that to >>packets with a header so the hci-usb.c layer has to deal with packets >>instead of samples. >>For 8 bit mono sound, SCO creates packets with 3 header bytes, and 24 >>sound samples. hci-usb.c then has to take each 27 byte packet and cut it >>down into 3 slices each 9 bytes in length. All packet sizes and slice >>sizes vary depending on 8/16 bits samples, and mono/stereo etc. > > > the seperate handling of ISOC is a good idea. Max told me that ISOC > URB's consumes USB bandwith and because of the fact that they are not > needed all the time, we have to start and stop them dynamicly, if a SCO > link is established or killed. The start and stop of ISOC will happen in the alsa snd_pcm_trigger call. The way an alsa application would work is: - snd_pcm_open snd_pcm_hwparam... (set format, # channels, buffer sizes etc.) snd_pcm_prepare (recover from under/over runs.) snd_pcm_trigger (actually start the stream with details from hwparm.) Then during sound output, the application might call snd_pcm_delay (returns difference between samples sent to the device, and samples that have actually been played.) snd_pcm_write (writes samples to ring buffer) snd_pcm_drop ( emply ring buffer) snd_pcm_close (stops the stream and frees resources.) As you can see, most of these are almost possible with the current sco interface, but snd_pcm_delay is definitly not present. The actual function call to the alsa low level driver is snd_pcm_get_postition(). So, my plan is to split the sco driver up a bit in accordance to your suggestion. (Maybe I did not make myself clear on that point) There will be a general section, that will handle calls for general sco access(ring buffer, pointers into ring buffer management, adding sco headers, handling sco connection connect/disconnect), and then there will be other sections for application specific stuff. E.g. The network interface, alsa interface, oss interface. My reasoning here is that if one has the oss interface, one will not need the alsa interface and visa versa, with the network interface being optional. It seems that alsa requires that all sound cards have ring buffers, and pointers into these buffers. These buffers are read and the pointers updated via callbacks from the sound hardware. It is this reason that I suggest that all playback and capture via a SCO connection should be handled with callbacks to the SCO layer from the HCI layer, with the SCO layer handling the ring buffer, updating pointers into the ring buffer and adding sco headers. Both alsa and oss have api calls to read these buffer pointers, and there is no such pointer api in the current bluez stack. Then all other higher layer modules (oss, alsa, network) would interface with this ring buffer. This would also have the benefit for providing flow control for the application. I.E. If the ring buffer is full, it blocks the write call. All ISOC connections are full-duplex, configurable fixed bandwidth, so the ring buffer will always be emptied at a fixed rate. Another suggestion is to do all the alloc of memory and creation of lists/queues at the snd_pcm_trigger stages, and not during tx/rx complete callbacks. > > My current idea of handling this is that the hci_usb driver checks for > SCO links in connection complete and disconnect complete events. Another > idea is to add another HCI driver method (for example hdev->notify), so > that the HCI core can notify the driver of special events or errors. I have not really thought about connect/disconnect yet, apart from linking it to snd_pcm_trigger/snd_pcm_close. I am concentrating of just getting reliable sound playback over a sco connection. I.e The ring buffer and rx/tx complete callbacks. > > >>So, there is going to be quite a lot of manipulation of the sound >>samples as they pass from alsa to the bluetooth device. >>The questions I am still trying to decide are: - >>1) When should the conversion from alsa ring buffer to packets take >>place. So far the only workable solution I have come up with is that the >>"hci_usb_tx_complete" makes a callback all the way to the sco layer, and >>the sco layer grabs 24 bytes form the alsa ring buffer, adds it's header >>and returns from the callback. >>2) interface to alsa. I think this should happen just above the SCO >>layer, but also ensuring that the SCO layer has enought api links with >>the hci-usb.c layer to be able to service all the alsa-driver api >>requirements. >>3) Once that all works, modify the other low level hardware drivers to >>work with it. e.g. bluecard_cs.c etc. > > > The native integration of Bluetooth audio within Linux is one of the > most wanted things. But we can't use ALSA for the 2.4 kernel, because it > is not a part of the kernel. For the 2.6 this is no problem, but I also > want to have support for OSS, because there will some people (like me) > which still uses OSS. Maybe split the sco driver into general helper api, and then separate modules for network, oss, alsa type interfaces into user land. > > The integration of audio is not part of the Bluetooth drivers, because > every Bluetooth HCI driver is only a transport driver which have to > transport the HCI command, event, ACL and SCO data between the hardware > and the HCI core layer. The SCO data would send from the HCI core > through the hdev->send() callback and the driver can send the SCO data > it gets from the hardware back with hci_recv_frame(). This means that > all needed modifications for ALSA and OSS integration have to done in > the HCI core or the SCO layer. And all other HCI drivers will still work > with SCO like they do now. The recv_frame() parts seem to work ok at the moment. (with some modifications as outlined in a previous email) The main problem is the send_frame() parts. hdev->send() is the wrong thing to do for ISOC connections (one runs into scheduling problems, buffer underruns and no flow control.). A callback method from the hardware is much beter. (e.g. Give me X number of samples NOW!). This is why I suggest a ring buffer and tx/rx complete callbacks from HCI to SCO layer to update ring buffer pointers, and then the alsa or oss layer above that. I will do alsa first because there is much less work involved. I know the callback/ringbuffer approach works well over usb, because alsa has a usb-audio driver, and it works fine. > > Regards > > Marcel > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bluez-devel] Re: Re: Bluetooth headset with Bluetooth usb dongle status. 2003-07-18 13:58 ` James Courtier-Dutton @ 2003-07-20 14:33 ` Jonathan Paisley 2003-07-22 0:23 ` Max Krasnyansky 2003-07-22 0:18 ` [Bluez-devel] " Max Krasnyansky 1 sibling, 1 reply; 12+ messages in thread From: Jonathan Paisley @ 2003-07-20 14:33 UTC (permalink / raw) To: bluez-devel On Fri, 18 Jul 2003 14:58:50 +0100, James Courtier-Dutton wrote: >>>The playback problem is a scheduling problem. The "hci_usb_tx_complete" >>>function uses the scheduler to kick off the next transmission, but the >>>scheduler is too slow, and the correct method to use is getting the >>>"hci_usb_tx_complete" function to retrieve the next packet to send from >>>a ring buffer, and send it immeadiately during the"hci_usb_tx_complete" I think this happens anyway: hci_usb_tx_complete() calls hci_usb_tx_wakeup() which calls hci_usb_tx_process() which calls hci_usb_send_isoc() which calls __tx_submit() which calls usb_submit_urb() Thus, if there is a new packet queued when the old one completes, the new one will be sent immediately. I have managed to get playback and recording (with the PC acting as a headset for my phone) to work well. I've made the following changes which are included in the patch at the end: (1) submit two rx urbs (same as your proposed patch, but done at caller) (2) allow two pending isoc urbs instead of one (3) only use the 9 byte (single voice channel) isoc endpoint Please let me know if you're able to reproduce this at your end. Thanks. diff -ur --exclude='.*' drivers/bluetooth.orig/hci_usb.c drivers/bluetooth/hci_usb.c --- drivers/bluetooth.orig/hci_usb.c 2003-07-20 15:25:49.000000000 +0100 +++ drivers/bluetooth/hci_usb.c 2003-07-20 15:19:20.000000000 +0100 @@ -302,6 +302,7 @@ #ifdef CONFIG_BLUEZ_USB_SCO if (husb->isoc_iface) + for (i = 0; i < HCI_MAX_ISOC_RX; i++) hci_usb_isoc_rx_submit(husb); #endif } else { @@ -522,7 +523,7 @@ #ifdef CONFIG_BLUEZ_USB_SCO /* Process SCO queue */ q = __transmit_q(husb, HCI_SCODATA_PKT); - if (!atomic_read(__pending_tx(husb, HCI_SCODATA_PKT)) && + if (atomic_read(__pending_tx(husb, HCI_SCODATA_PKT)) < HCI_MAX_ISOC_TX && (skb = skb_dequeue(q))) { if (hci_usb_send_isoc(husb, skb) < 0) skb_queue_head(q, skb); @@ -830,7 +831,7 @@ #ifdef CONFIG_BLUEZ_USB_SCO case USB_ENDPOINT_XFER_ISOC: - if (ep->wMaxPacketSize < size) + if (ep->wMaxPacketSize != 9) break; size = ep->wMaxPacketSize; Only in drivers/bluetooth: hci_usb.c.orig diff -ur --exclude='.*' drivers/bluetooth.orig/hci_usb.h drivers/bluetooth/hci_usb.h --- drivers/bluetooth.orig/hci_usb.h 2003-07-20 15:25:49.000000000 +0100 +++ drivers/bluetooth/hci_usb.h 2003-07-20 14:20:43.000000000 +0100 @@ -41,6 +41,9 @@ #define HCI_MAX_BULK_TX 4 #define HCI_MAX_BULK_RX 1 +#define HCI_MAX_ISOC_RX 2 +#define HCI_MAX_ISOC_TX 2 + #define HCI_MAX_ISOC_FRAMES 10 struct _urb_queue { ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ Bluez-devel mailing list Bluez-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bluez-devel] Re: Re: Bluetooth headset with Bluetooth usb dongle status. 2003-07-20 14:33 ` [Bluez-devel] " Jonathan Paisley @ 2003-07-22 0:23 ` Max Krasnyansky 2003-07-22 1:10 ` James Courtier-Dutton 2003-07-22 13:35 ` jp-www 0 siblings, 2 replies; 12+ messages in thread From: Max Krasnyansky @ 2003-07-22 0:23 UTC (permalink / raw) To: Jonathan Paisley, bluez-devel At 07:33 AM 7/20/2003, Jonathan Paisley wrote: >I have managed to get playback and recording (with the PC acting as a >headset for my phone) to work well. I've made the following changes which >are included in the patch at the end: > > (1) submit two rx urbs (same as your proposed patch, but done at caller) > (2) allow two pending isoc urbs instead of one > (3) only use the 9 byte (single voice channel) isoc endpoint I buy #1 and #2, although I'm surprised that it's supported by HCD. But 9 bytes packets ? Max ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ Bluez-devel mailing list Bluez-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bluez-devel] Re: Re: Bluetooth headset with Bluetooth usb dongle status. 2003-07-22 0:23 ` Max Krasnyansky @ 2003-07-22 1:10 ` James Courtier-Dutton 2003-07-22 17:46 ` Max Krasnyansky 2003-07-22 13:35 ` jp-www 1 sibling, 1 reply; 12+ messages in thread From: James Courtier-Dutton @ 2003-07-22 1:10 UTC (permalink / raw) To: Max Krasnyansky; +Cc: Jonathan Paisley, bluez-devel Max Krasnyansky wrote: > At 07:33 AM 7/20/2003, Jonathan Paisley wrote: > >>I have managed to get playback and recording (with the PC acting as a >>headset for my phone) to work well. I've made the following changes which >>are included in the patch at the end: >> >> (1) submit two rx urbs (same as your proposed patch, but done at caller) >> (2) allow two pending isoc urbs instead of one >> (3) only use the 9 byte (single voice channel) isoc endpoint > > I buy #1 and #2, although I'm surprised that it's supported by HCD. > But 9 bytes packets ? Read the bluetooth headset specification. For 8000hz 8 bit mono sound. > > Max > ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ Bluez-devel mailing list Bluez-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bluez-devel] Re: Re: Bluetooth headset with Bluetooth usb dongle status. 2003-07-22 1:10 ` James Courtier-Dutton @ 2003-07-22 17:46 ` Max Krasnyansky 2003-07-22 17:56 ` jp-www 0 siblings, 1 reply; 12+ messages in thread From: Max Krasnyansky @ 2003-07-22 17:46 UTC (permalink / raw) To: James Courtier-Dutton; +Cc: Jonathan Paisley, bluez-devel At 06:10 PM 7/21/2003, James Courtier-Dutton wrote: >Max Krasnyansky wrote: >>At 07:33 AM 7/20/2003, Jonathan Paisley wrote: >> >>>I have managed to get playback and recording (with the PC acting as a >>>headset for my phone) to work well. I've made the following changes which >>>are included in the patch at the end: >>> >>> (1) submit two rx urbs (same as your proposed patch, but done at caller) >>> (2) allow two pending isoc urbs instead of one >>> (3) only use the 9 byte (single voice channel) isoc endpoint >>I buy #1 and #2, although I'm surprised that it's supported by HCD. >>But 9 bytes packets ? >Read the bluetooth headset specification. For 8000hz 8 bit mono sound. Bluetooth headset spec has nothing to do with HCI over _USB_. USB is just one of the defined transports for HCI. Max ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ Bluez-devel mailing list Bluez-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bluez-devel] Re: Re: Bluetooth headset with Bluetooth usb dongle status. 2003-07-22 17:46 ` Max Krasnyansky @ 2003-07-22 17:56 ` jp-www 0 siblings, 0 replies; 12+ messages in thread From: jp-www @ 2003-07-22 17:56 UTC (permalink / raw) To: Max Krasnyansky; +Cc: James Courtier-Dutton, bluez-devel On Tue, 22 Jul 2003 10:46am -0700, Max Krasnyansky wrote: > At 06:10 PM 7/21/2003, James Courtier-Dutton wrote: > >Max Krasnyansky wrote: > >>At 07:33 AM 7/20/2003, Jonathan Paisley wrote: > >> > >>>I have managed to get playback and recording (with the PC acting as a > >>>headset for my phone) to work well. I've made the following changes which > >>>are included in the patch at the end: > >>> > >>> (1) submit two rx urbs (same as your proposed patch, but done at caller) > >>> (2) allow two pending isoc urbs instead of one > >>> (3) only use the 9 byte (single voice channel) isoc endpoint > >>I buy #1 and #2, although I'm surprised that it's supported by HCD. > >>But 9 bytes packets ? > >Read the bluetooth headset specification. For 8000hz 8 bit mono sound. > > Bluetooth headset spec has nothing to do with HCI over _USB_. USB is just one > of the defined transports for HCI. James has mentioned the /headset/ specification, when I assume that he meant the HCI over USB section of the BT spec. I got the info for my original patch from: Page 788 of Bluetooth_1_1_vol1.pdf Part H:2 HCI USB Transport Layer Section 2.1 USB Endpoint Expectations, Endpoint Overview ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ Bluez-devel mailing list Bluez-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bluez-devel] Re: Re: Bluetooth headset with Bluetooth usb dongle status. 2003-07-22 0:23 ` Max Krasnyansky 2003-07-22 1:10 ` James Courtier-Dutton @ 2003-07-22 13:35 ` jp-www 1 sibling, 0 replies; 12+ messages in thread From: jp-www @ 2003-07-22 13:35 UTC (permalink / raw) To: Max Krasnyansky; +Cc: bluez-devel On Mon, 21 Jul 2003 5:23pm -0700, Max Krasnyansky wrote: > At 07:33 AM 7/20/2003, Jonathan Paisley wrote: > >I have managed to get playback and recording (with the PC acting as a > >headset for my phone) to work well. I've made the following changes which > >are included in the patch at the end: > > > > (1) submit two rx urbs (same as your proposed patch, but done at caller) > > (2) allow two pending isoc urbs instead of one > > (3) only use the 9 byte (single voice channel) isoc endpoint > I buy #1 and #2, although I'm surprised that it's supported by HCD. > But 9 bytes packets ? I must admit that I don't fully understand what's going on... The SCO socket reports mtu 64 bytes. The read() on the socket returns 24 bytes at a time. Thus, I'm also sending 24 bytes with send() -- sending more results in no audio on the remote device. There's some question about how this data relates to the timings described in the example in the specification. How does this 24 byte message correspond to the 9 byte endpoint? I see that the SCO packets have a handle and length header (3 bytes): typedef struct { __u16 handle; __u8 dlen; } __attribute__ ((packed)) hci_sco_hdr; so I suppose the 24 byte message becomes 27 bytes with the header, which gets divided into 3 x 9 byte packets. I'm using an ohci interface, but will try things on a uhci interface in another computer to see how it copes with (1) and (2) from my original message. ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ Bluez-devel mailing list Bluez-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bluez-devel] Re: Bluetooth headset with Bluetooth usb dongle status. 2003-07-18 13:58 ` James Courtier-Dutton 2003-07-20 14:33 ` [Bluez-devel] " Jonathan Paisley @ 2003-07-22 0:18 ` Max Krasnyansky 1 sibling, 0 replies; 12+ messages in thread From: Max Krasnyansky @ 2003-07-22 0:18 UTC (permalink / raw) To: James Courtier-Dutton, Marcel Holtmann; +Cc: bluez Dev At 06:58 AM 7/18/2003, James Courtier-Dutton wrote: >>The integration of audio is not part of the Bluetooth drivers, because >>every Bluetooth HCI driver is only a transport driver which have to >>transport the HCI command, event, ACL and SCO data between the hardware >>and the HCI core layer. The SCO data would send from the HCI core >>through the hdev->send() callback and the driver can send the SCO data >>it gets from the hardware back with hci_recv_frame(). This means that >>all needed modifications for ALSA and OSS integration have to done in >>the HCI core or the SCO layer. And all other HCI drivers will still work >>with SCO like they do now. >The recv_frame() parts seem to work ok at the moment. (with some modifications as outlined in a previous email) >The main problem is the send_frame() parts. hdev->send() is the wrong thing to do for ISOC connections (one runs into scheduling problems, buffer underruns and no flow control.). I'm still not sure what scheduler problems you're talking about. Current send process looks like this: app -> sco socket layer -> hci core -> (soft irq) -> hci tx tasklet -> hci driver -> HW I guess by scheduler you mean scheduling tasklet. But tasklet is extremely fast (we can elevate tasklet priority if needed) it doesn't go via normal process scheduler, it's softirq within the kernel itself no context switching, etc. >A callback method from the hardware is much beter. (e.g. Give me X number of samples NOW!). This is why I suggest a ring buffer and tx/rx complete callbacks from HCI to SCO layer to update ring buffer pointers, and then the alsa or oss layer above that. >I will do alsa first because there is much less work involved. >I know the callback/ringbuffer approach works well over usb, because alsa has a usb-audio driver, and it works fine. The problem is that with PCMCIA, UART, etc based devices you don't know when transfer completes. ie In USB you submit URB, it completes, you get a callback, in PCMCIA you're not going to get any completion callbacks. Also one Bluetooth device can have up to 3 SCO connections information about connection handles and stuff is maintained by the HCI core. Which means HCI driver has to talk to the core anyway. Max ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bluez-devel] Re: Bluetooth headset with Bluetooth usb dongle status. 2003-07-18 13:04 ` Marcel Holtmann 2003-07-18 13:58 ` James Courtier-Dutton @ 2003-07-21 23:53 ` Max Krasnyansky 1 sibling, 0 replies; 12+ messages in thread From: Max Krasnyansky @ 2003-07-21 23:53 UTC (permalink / raw) To: Marcel Holtmann, James Courtier-Dutton; +Cc: bluez Dev At 06:04 AM 7/18/2003, Marcel Holtmann wrote: >> So, there is going to be quite a lot of manipulation of the sound >> samples as they pass from alsa to the bluetooth device. >> The questions I am still trying to decide are: - >> 1) When should the conversion from alsa ring buffer to packets take >> place. So far the only workable solution I have come up with is that the >> "hci_usb_tx_complete" makes a callback all the way to the sco layer, and >> the sco layer grabs 24 bytes form the alsa ring buffer, adds it's header >> and returns from the callback. >> 2) interface to alsa. I think this should happen just above the SCO >> layer, but also ensuring that the SCO layer has enought api links with >> the hci-usb.c layer to be able to service all the alsa-driver api >> requirements. >> 3) Once that all works, modify the other low level hardware drivers to >> work with it. e.g. bluecard_cs.c etc. > >The native integration of Bluetooth audio within Linux is one of the >most wanted things. But we can't use ALSA for the 2.4 kernel, because it >is not a part of the kernel. For the 2.6 this is no problem, but I also >want to have support for OSS, because there will some people (like me) >which still uses OSS. Those people will have to upgrade :). New stuff like this audio support should be developed in 2.6. >The integration of audio is not part of the Bluetooth drivers, because >every Bluetooth HCI driver is only a transport driver which have to >transport the HCI command, event, ACL and SCO data between the hardware >and the HCI core layer. The SCO data would send from the HCI core >through the hdev->send() callback and the driver can send the SCO data >it gets from the hardware back with hci_recv_frame(). This means that >all needed modifications for ALSA and OSS integration have to done in >the HCI core or the SCO layer. And all other HCI drivers will still work >with SCO like they do now. 150% agree. Max ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bluez-devel] Re: Bluetooth headset with Bluetooth usb dongle status. 2003-07-18 12:15 ` [Bluez-devel] Re: Bluetooth headset with Bluetooth usb dongle status James Courtier-Dutton 2003-07-18 13:04 ` Marcel Holtmann @ 2003-07-21 23:49 ` Max Krasnyansky 1 sibling, 0 replies; 12+ messages in thread From: Max Krasnyansky @ 2003-07-21 23:49 UTC (permalink / raw) To: James Courtier-Dutton, bluez Dev At 05:15 AM 7/18/2003, James Courtier-Dutton wrote: >There are a number of problems with the current usb-hci.c driver. >I have a dirty fix for sound recording, but playback will need a lot of work. >If you want recording to work, just put in a for loop round the >"static int hci_usb_isoc_rx_submit(struct hci_usb *husb)" function to make it execute twice. See "e.g." below. > >It is a very dirty fix, because I don't think that everything gets freed when not in use, but at least it records sound at the correct speed. Actually it's not a dirty fix. I thought that ISOC queuing (ie more than one transfer at a time) is not support by USB HCD driver. If it supported then the fix is good. >The playback problem is a scheduling problem. >The "hci_usb_tx_complete" function uses the scheduler to kick off the next transmission, but the scheduler is too slow, and the correct method to use is getting the "hci_usb_tx_complete" function to retrieve the next packet to send from a ring buffer, and send it immeadiately during the "hci_usb_tx_complete" function. Which scheduler are you're talking about ? Take a look at hci_usb_tx_proccess() function, which is called immediately after transfer completes, it does this: /* Process SCO queue */ q = __transmit_q(husb, HCI_SCODATA_PKT); if (!atomic_read(__pending_tx(husb, HCI_SCODATA_PKT)) && (skb = skb_dequeue(q))) { if (hci_usb_send_isoc(husb, skb) < 0) skb_queue_head(q, skb); } So basically HCI USB driver has SCO TX queue and the next packet, if available, is retrived directly from this queue. Scheduler is not involved here. Again it only does one transfer at a time because I thought (and still think :)) that multiple ISOC transfers are not supported. >This is how the current usbaudio.c does it, so it proves that this method will work. >So, I will need to implement a ring buffer. >At the same time I want to implement sound output via alsa, so I want to make sure we have a good api to achieve that. >alsa requires certain information from the sound card (ring buffer position etc.), and I will have to make sure that the information alsa needs in available, by maybe adding new api calls through the sco layer to the usb-hci.c layer. Those calls should be made into HCI core not HCI USB driver. Think about PCI and PCMCIA and other Bluetooth devices. We have to make audio support generic. >I think it would be a good idea to completely separate the isoc(sound) urb path from the int/bulk/control urb path. I completely disagree. Most of the URB processing is very similar. First version of the driver did have separate bulk and isoc paths, but the code was pretty much the same that's why it's been combined. >We also have the added complication that the alsa ring buffer is composed of just sound samples, but the sco layer converts that to packets with a header so the hci-usb.c layer has to deal with packets instead of samples. >For 8 bit mono sound, SCO creates packets with 3 header bytes, and 24 sound samples. hci-usb.c then has to take each 27 byte packet and cut it down into 3 slices each 9 bytes in length. All packet sizes and slice sizes vary depending on 8/16 bits samples, and mono/stereo etc. > >So, there is going to be quite a lot of manipulation of the sound samples as they pass from alsa to the bluetooth device. >The questions I am still trying to decide are: - >1) When should the conversion from alsa ring buffer to packets take place. So far the only workable solution I have come up with is that the >"hci_usb_tx_complete" makes a callback all the way to the sco layer, and the sco layer grabs 24 bytes form the alsa ring buffer, adds it's header and returns from the callback. Why can't we just pass those samples to the HCI USB driver as soon as they become available ? Driver will put queue them into tx queue and use that queue when transfer completes. >2) interface to alsa. I think this should happen just above the SCO layer, but also ensuring that the SCO layer >has enought api links with the hci-usb.c layer to be able to service all the alsa-driver api requirements. By SCO layer you actually mean HCI core. Current SCO layer that we have is a simple raw socket interface nothing else. So ALSA Bluetooth sound cart driver will completely current SCO layer. >3) Once that all works, modify the other low level hardware drivers to work with it. e.g. bluecard_cs.c etc. That's why we have to go though HCI core from the beginning. If we do it right all other drivers will just work. >The final result will be: - >1) a small tool that will link a particular paired bluetooth device to a particular PCM device for alsa to work with. This tool will basically just take destination BTADDR and channel number to use, because alsa will have no knowledge of that sort of info. It will add a new sound card instance for each bluetooth device. >2) alsa will just think that the bluetooth headset is a normal soundcard. >3) This would make integration with current audio applications simple, because alsa supports the alsa-api as well as emulate the oss-api, so current audio applications would need no changes. >4) We could even implement headset "in the vicinity" detection, so that when the headset transitioned from out of range to in range, your computer could say hello! That's exactly what I had in mind. I was even going to start looking into ALSA architecture. Max ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ Bluez-devel mailing list Bluez-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2003-07-22 17:56 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <E19a5DI-0002jL-00@sc8-sf-list2.sourceforge.net> [not found] ` <3F1752C5.5020701@dsto.defence.gov.au> 2003-07-18 12:15 ` [Bluez-devel] Re: Bluetooth headset with Bluetooth usb dongle status James Courtier-Dutton 2003-07-18 13:04 ` Marcel Holtmann 2003-07-18 13:58 ` James Courtier-Dutton 2003-07-20 14:33 ` [Bluez-devel] " Jonathan Paisley 2003-07-22 0:23 ` Max Krasnyansky 2003-07-22 1:10 ` James Courtier-Dutton 2003-07-22 17:46 ` Max Krasnyansky 2003-07-22 17:56 ` jp-www 2003-07-22 13:35 ` jp-www 2003-07-22 0:18 ` [Bluez-devel] " Max Krasnyansky 2003-07-21 23:53 ` Max Krasnyansky 2003-07-21 23:49 ` Max Krasnyansky
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.