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
[email protected]
https://lists.sourceforge.net/lists/listinfo/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
[email protected]
https://lists.sourceforge.net/lists/listinfo/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
[email protected]
https://lists.sourceforge.net/lists/listinfo/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
[email protected]
https://lists.sourceforge.net/lists/listinfo/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
[email protected]
https://lists.sourceforge.net/lists/listinfo/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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel