Slow connection to Motorola H500 Headset
Hi,
I am trying to use my Motorola Headset H500 as a bluetooth audio device.
Audio transfer is working perfectly in both directions, the only minor annoyance is that it takes several seconds for every connection to be established.
This makes it difficult to use the headset as an audio device for VoIP as there is a gap of up to 5 seconds between pressing 'accept call' and an established audio connection.
These connection delays also happen with using a simple:
aplay -D plughw:Headset soundfile.wav
I am running Ubuntu Dapper with kernel 2.6.15, bluez-utils 2.24, snd-bt-sco 1.11 and btsco v0.42.
btsco -v <addr> shows:
btsco v0.42
Device is 1:0
Voice setting: 0x0060
RFCOMM channel 2 connected
Using interface hci0
recieved AT+BRSF=26
speaker volume: 7 mic volume: 1
i/o needed: connecting sco...
<several seconds here>
connected SCO channel
Done setting sco fd
recieved AT+VGS=07
Sending up speaker change 7
speaker volume: 7 mic volume: 1
driver is not in use
disconnected SCO channel
and hcidump -t shows:
1150745951.394107 < HCI Command: Add SCO Connection (0x01|0x0007) plen 4 1150745951.399620 > HCI Event: Command Status (0x0f) plen 4 1150745956.366798 > HCI Event: Connect Complete (0x03) plen 11 1150745956.389809 > SCO data: handle 41 dlen 48 1150745956.389813 > SCO data: handle 41 dlen 48 1150745956.389818 > SCO data: handle 41 dlen 48 1150745956.389888 < SCO data: handle 41 dlen 48 1150745956.389912 < SCO data: handle 41 dlen 48 1150745956.389930 < SCO data: handle 41 dlen 48
Can I do anything to avoid these delays?
Thanks for any hints.
Regards,
Christoph
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Christoph
Quoted 3 lines
Audio transfer is working perfectly in both directions, the only minor annoyance is that it takes several seconds for every connection to be established.
maybe the headset is parking itself between connections. I don't know much about what can be done to influence its policy though.
you could start up hcidump before you bring up the headset and tell us what the dump looks like at the start. we might be able to tell what slows things down.
Brad
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Brad,
thanks for your quick reply.
Quoted 6 lines
Quoted 3 lines
Audio transfer is working perfectly in both directions, the only minor annoyance is that it takes several seconds for every connection to be established.
maybe the headset is parking itself between connections. I don't know much about what can be done to influence its policy though.
It seems as if the headset enters some kind of 'powersave' mode after a few seconds.
Quoted 3 lines
you could start up hcidump before you bring up the headset and tell us what the dump looks like at the start. we might be able to tell what slows things down.
I did the following steps to produce the two attached hcidumps:
hcidump.log.fast.gz:
* start hcidump
* switch headset on
* wait for link key request and immediately start btsco
* wait for btsco to be ready and immediately start aplay => This results in an immediately starting audio playback
hcidump.log.slow.gz:
* start hcidump
* switch headset on
* wait for link key request and immediately start btsco
* wait about 30 sec. after btsco being ready before starting aplay => This results in an delay of 3-5 seconds before audio playback is starting
This behaviour is reproducable.
If anybody has any hints what is happening here that would be great.
Thanks in advance,
Christoph
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Brad,
thanks for your quick reply.
Quoted 6 lines
Quoted 3 lines
Audio transfer is working perfectly in both directions, the only minor annoyance is that it takes several seconds for every connection to be established.
maybe the headset is parking itself between connections. I don't know much about what can be done to influence its policy though.
It seems as if the headset enters some kind of 'powersave' mode after a few seconds.
Quoted 3 lines
you could start up hcidump before you bring up the headset and tell us what the dump looks like at the start. we might be able to tell what slows things down.
I did the following steps to produce the two attached hcidumps:
hcidump-fast.gz:
* start hcidump
* switch headset on
* wait for link key request and immediately start btsco
* wait for btsco to be ready and immediately start aplay => This results in an immediately starting audio playback
hcidump-slow.gz:
* start hcidump
* switch headset on
* wait for link key request and immediately start btsco
* wait about 30 sec. after btsco being ready before starting aplay => This results in an delay of 3-5 seconds before audio playback is starting
This behaviour is reproducable.
If anybody has any hints what is happening here that would be great.
Thanks in advance,
Christoph
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi,
I have digged some further into this and found out the following:
Just after pairing the headset l2ping shows ping times of about 45 msec. After starting btsco and about 5 sec after btsco has connected hcidump shows:
1152107748.832103 < ACL data: handle 42 flags 0x02 dlen 9
L2CAP(d): cid 0x0042 len 5 [psm 3]
RFCOMM(d): UIH: cr 1 dlci 2 pf 1 ilen 0 fcs 0x86 credits 33
1152107748.835034 > ACL data: handle 42 flags 0x02 dlen 9
L2CAP(d): cid 0x0041 len 5 [psm 3]
RFCOMM(d): UIH: cr 0 dlci 2 pf 1 ilen 0 fcs 0x5c credits 151152107748.840034 > HCI Event: Number of Completed Packets (0x13) plen 5 1152107754.511244 > HCI Event: Mode Change (0x14) plen 6
After this last 'Mode Change' is received l2ping takes 4000-6000 msec which corresponds to the delay in starting audio playback.
Additionally the hcidump for l2ping -c1 looks different (btsco running):
This is before we receive HCI Event: Mode Change (0x14) plen 6:
1152108661.495583 < ACL data: handle 43 flags 0x02 dlen 52
L2CAP(s): Echo req: dlen 44
1152108661.516393 > HCI Event: Number of Completed Packets (0x13) plen 5
1152108661.546387 > ACL data: handle 43 flags 0x02 dlen 27
1152108661.548386 > ACL data: handle 43 flags 0x01 dlen 25
L2CAP(s): Echo rsp: dlen 44and this after we received HCI Event: Mode Change (0x14) plen 6:
1152106935.430096 < ACL data: handle 42 flags 0x02 dlen 52
L2CAP(s): Echo req: dlen 44
1152106936.918474 > HCI Event: Number of Completed Packets (0x13) plen 5 1152106939.474570 > ACL data: handle 42 flags 0x02 dlen 17 1152106939.476566 > ACL data: handle 42 flags 0x01 dlen 17 1152106939.477589 > ACL data: handle 42 flags 0x01 dlen 17 1152106939.478582 > ACL data: handle 42 flags 0x01 dlen 1
L2CAP(s): Echo rsp: dlen 44
can anybody tell me what this 'HCI Event: Mode Change (0x14) plen 6' is about and probably how to prevent this?
A full hcidump from pairing the headset and starting btsco is attached.
Thanks in advance,
Christoph
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Christoph,
Quoted 3 lines
can anybody tell me what this 'HCI Event: Mode Change (
0x14) plen 6' is about and probably how to prevent this?
A full hcidump from pairing the headset and starting btsco is attached.
First of all, hcidump produce better output when you use -X and -V switches. :-)
Well, this mode change event is turning the connection to sniff mode, probably to save some power. And according to your dump the command to change the connection mode was sent by your headset. Looking closer we can see that the interval between two sniff anchor points is 4096 baseband slots that give us 2.56 seconds! This really seems to be overkill and it's probably causing the delay you're experiencing.
I don't think there's something you can do to avoid this. btsco could change the link policy settings to remove sniff mode, but this would require root privileges and I really don't think btsco shoud do that. Marcel, am I right or is there anything that might be done and I don't know?
Best regards,
-- Ulisses
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Ulisses,
thanks for your reply.
Quoted 5 lines
Quoted 3 lines
can anybody tell me what this 'HCI Event: Mode Change (
0x14) plen 6' is about and probably how to prevent this?
A full hcidump from pairing the headset and starting btsco is attached.First of all, hcidump produce better output when you use -X and -V switches. :-)
Ah, thanks. That would have made it easier.
Quoted 6 lines
Well, this mode change event is turning the connection to sniff mode, probably to save some power. And according to your dump the command to change the connection mode was sent by your headset. Looking closer we can see that the interval between two sniff anchor points is 4096 baseband slots that give us 2.56 seconds! This really seems to be overkill and it's probably causing the delay you're experiencing.
Ok. That sounds reasonable.
Quoted 5 lines
I don't think there's something you can do to avoid this. btsco could change the link policy settings to remove sniff mode, but this would require root privileges and I really don't think btsco shoud do that. Marcel, am I right or is there anything that might be done and I don't know?
In a first try I have used hciconfig to disable sniff mode completely on hci0:
hciconfig hci0 lp RSWITCH,HOLD,PARK
This made my headset working perfectly!
You are my hero!
Are there any negative side effect of disabling sniff mode? Is it needed for some devices?
Thanks a lot,
Christoph
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On 7/7/06, Christoph Lukas <[email protected]> wrote:
Hi Christoph,
Quoted 10 lines
In a first try I have used hciconfig to disable sniff mode completely on hci0:
hciconfig hci0 lp RSWITCH,HOLD,PARK
This made my headset working perfectly!
You are my hero!
Are there any negative side effect of disabling sniff mode?
Yeah, I didn't say but you could have done just that. Though it disables the sniff mode for all ACL connections using the hci0 adapter and we usually don't want this because several devices use the sniff mode to save battery. Thus the negative side effect you might notice is that your devices will probably run out of battery much earlier than before.
FWIW, I think that your headset doesn't make use of sniff mode correctly.
Quoted 1 line
Is it needed for some devices?
I really don't know if the sniff mode is mandatory for some devices, but I do know that some keyboards/mice like to be in sniff mode all the time.
Best regards,
-- Ulisses
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Ulisses,
Quoted 8 lines
Quoted 1 line
Are there any negative side effect of disabling sniff mode?
Yeah, I didn't say but you could have done just that. Though it disables the sniff mode for all ACL connections using the hci0 adapter and we usually don't want this because several devices use the sniff mode to save battery. Thus the negative side effect you might notice is that your devices will probably run out of battery much earlier than before.
Does entering the sniff mode even save power on the notebooks bluetooth device?
Quoted 1 line
FWIW, I think that your headset doesn't make use of sniff mode correctly.
Do you know any possibility to force a smaller sniff interval for this device? Something like 250 msec instead of 2.5 sec? That would probably be the best solution.
Thanks a lot for your help,
Christoph
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Christoph,
Quoted 2 lines
Does entering the sniff mode even save power on the notebooks bluetooth device?
Yes, it should save power but the sniff mode is more important in small devices like mobile phones, keyboards, mice, and so on.
Quoted 3 lines
Do you know any possibility to force a smaller sniff interval for this device? Something like 250 msec instead of 2.5 sec? That would probably be the best solution.
You can try the automatic sniff mode feature that probably is going to be on Linux kernel 2.6.18 (and it's also present on Marcel Holtmann's -mh patches). It sniffs the connection after a period of inactivity and it uses a sniff interval of 500 milliseconds. You can specify the period of inactivity after which the connection must be sniffed with:
# echo 6000 > /sys/class/bluetooth/hci0/idle_timeout
This would make an idle ACL connection go to sniff mode after 6 seconds. You can disable this feature (if you need to) with:
# echo 0 > /sys/class/bluetooth/hci0/idle_timeout
You can play with this idle timeout sysfs entry and see if things get better for you. :-)
Best regards,
-- Ulisses
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users