* [Bluez-devel] btsco - a few comments and a small .py script @ 2005-08-19 19:38 Andreas Beck 2005-08-19 20:44 ` John Gruenenfelder 2005-08-20 20:13 ` Brad Midgley 0 siblings, 2 replies; 12+ messages in thread From: Andreas Beck @ 2005-08-19 19:38 UTC (permalink / raw) To: bluez-devel Hi folks, I've played around with btsco the last few days - now it sort of works like intended. I got the following comments about the procedure: 1. I'd like to suggest to put the comment about compatible dongles on the btsco website a little clearer. "If it doesn't say anything at all about SCO mapping, " wasn't clear to me (being a bluetooth newbie), as it was "displaying something with SCO" (i.e. the MTU, but I didn't grasp the difference at first, as my first adapter didn't show more than the first 2 lines). I'd suggest to put a simple exaple there, how the results from "hciconfig hci0 revision" should look like. I.e. that the line "SCO mapping: HCI" should exist. 2. I think the following comment might be something for the BlueZ-FAQ, as I have seen more people with this problem, while googling for a solution: Q: I have used the same bluetooth dongle on different machines or with different machine configurations (e.g. using windows). Now my device will refuse to pair again with the dongle. A: Remove the line in /var/lib/bluetooth/[my-bdaddr]/linkkeys that is corresponding to the device that doesn't want to pair. BlueZ thinks it is already paired, but the Link-Key does not match. Another - maybe better - solution would be to initiate a re-pair request in case the Link fails due to wrong keys. I had the case that I first tested the newly bought (CSR) dongle using the laptop, while I actually wanted to use it on the desktop later. After being paired with the laptop, the headset refused to pair with the desktop with the same dongle. I've seen a rather recent question that seems to be the same problem on bluez-users. However the hints there point to /etc/bluetooth/linkkeys - is this outdated or is this due to me using debian packages? Another - possibly very interesting - solution would be to allow to change the bdaddr in software. This would allow me to fake the same dongle to have two different bdaddrs depending on where I use it, thus allowing the headset to correctly pair with _both_ devices, so that I only need to move the dongle and everything works. Is there such a command? Please excuse, if it is obvious. I'm very new to this stuff. 3. I have written a small Python-Script and a .btscorc that allows me to pick up Skype calls with the headset button. I got to hold the button, as it otherwise will just change the volume and reacting on those AT sequences didn't seem like a good idea to me. I'm not sure, if the AT-command is always the same, but that's easy enough to adjust. The files are at: http://www.acs.uni-duesseldorf.de/~becka/download/skype/ The python script is probably ugly. I have no clue abou python - I just mangled the skype sample script. 4. I also have the "microphone transmits noise" problem sometimes (rarely). Could it be, that there is a missed byte that swaps high and lowbyte? It sounded a bit like this to me. 5. My cheap (EUR 22.- incl. VAT) LevelOne BLH-1000 Headset works fine, except for the glitch just described. It ignores microphone level setup, though. Loopback control works. Using the buttons, you can only reach Speaker Level 12 (80%) - using the mixer you can go to 100%. Have fun, Andy ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ 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] btsco - a few comments and a small .py script 2005-08-19 19:38 [Bluez-devel] btsco - a few comments and a small .py script Andreas Beck @ 2005-08-19 20:44 ` John Gruenenfelder 2005-08-20 20:13 ` Brad Midgley 1 sibling, 0 replies; 12+ messages in thread From: John Gruenenfelder @ 2005-08-19 20:44 UTC (permalink / raw) To: bluez-devel On Fri, Aug 19, 2005 at 09:38:55PM +0200, Andreas Beck wrote: >Q: I have used the same bluetooth dongle on different machines or with >different machine configurations (e.g. using windows). Now my device >will refuse to pair again with the dongle. > >A: Remove the line in /var/lib/bluetooth/[my-bdaddr]/linkkeys that is >corresponding to the device that doesn't want to pair. BlueZ thinks it >is already paired, but the Link-Key does not match. > > I've seen a rather recent question that seems to be the same problem > on bluez-users. However the hints there point to > /etc/bluetooth/linkkeys - is this outdated or is this due to me using > debian packages? This was my experience. My device simply stopped working after I had used it on another machine (same dongle though). I am also using the Debian packages and there is no /etc/bluetooth/linkkeys. For me, the problem manifested itself as "input/output error" messages when trying most bluetooth commands or btsco. That's not a lot of help. Eventually, somebody in my local users group tipped me off to the location of the link keys as /var/lib/bluetooth and after deleting the offending files, my headset could be paired again and it works now. This seems, to me, to be a bug on both ends. Bug 1) When you list the files in the Debian bluez packages, /var/lib/bluetooth is not listed. This is a clear packaging bug as that directory should definitely be listed therein, even if the package doesn't actually ship with any files *in* that directory (they are program generated). Bug 2) When the bluez tools (hcitool I think) are told to remove a key, they do not do so. That also made tracking down my problem harder. Thinking it was a key issue, the command to delete the key was given, but it didn't seem to do anything. Only manually deleting the file off the filesystem did the trick. -- --John Gruenenfelder Research Assistant, Steward Observatory, U of Arizona johng@as.arizona.edu Try Weasel Reader for PalmOS -- http://gutenpalm.sf.net "This is the most fun I've had without being drenched in the blood of my enemies!" --Sam of Sam & Max ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ 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] btsco - a few comments and a small .py script 2005-08-19 19:38 [Bluez-devel] btsco - a few comments and a small .py script Andreas Beck 2005-08-19 20:44 ` John Gruenenfelder @ 2005-08-20 20:13 ` Brad Midgley 2005-08-21 12:12 ` Andreas Beck 2005-08-21 19:26 ` Andreas Beck 1 sibling, 2 replies; 12+ messages in thread From: Brad Midgley @ 2005-08-20 20:13 UTC (permalink / raw) To: bluez-devel Andreas, > I've played around with btsco the last few days - now it sort of works > like intended. great > I got the following comments about the procedure: > > 1. I'd like to suggest to put the comment about compatible dongles on > the btsco website a little clearer. > > "If it doesn't say anything at all about SCO mapping, " wasn't clear > to me (being a bluetooth newbie), as it was "displaying something > with SCO" (i.e. the MTU, but I didn't grasp the difference at first, > as my first adapter didn't show more than the first 2 lines). > > I'd suggest to put a simple exaple there, how the results from > "hciconfig hci0 revision" should look like. I.e. that the line > "SCO mapping: HCI" should exist. I cleaned this up a bit. > A: Remove the line in /var/lib/bluetooth/[my-bdaddr]/linkkeys that is > corresponding to the device that doesn't want to pair. BlueZ thinks it > is already paired, but the Link-Key does not match. > > Another - possibly very interesting - solution would be to allow to > change the bdaddr in software. This would allow me to fake the same > dongle to have two different bdaddrs depending on where I use it, > thus allowing the headset to correctly pair with _both_ devices, > so that I only need to move the dongle and everything works. > > Is there such a command? Please excuse, if it is obvious. I'm very > new to this stuff. I don't know of such a command. /etc/bluetooth/link_key is how the keys are stored in the older daemon so I've mentioned both in the docs. > 3. I have written a small Python-Script and a .btscorc Perfect. I gave a talk about btsco at our usergroup meeting and this very question came up! (slides at http://flamebot.com/blog) I will link to you or put these in a contrib dir (what do you think?) > 4. I also have the "microphone transmits noise" problem sometimes > (rarely). Could it be, that there is a missed byte that swaps high > and lowbyte? It sounded a bit like this to me. I think you are right. There is some kind of fundamental transport glitch. > 5. My cheap (EUR 22.- incl. VAT) LevelOne BLH-1000 Headset works fine, > except for the glitch just described. It ignores microphone level > setup, though. Loopback control works. Using the buttons, you can > only reach Speaker Level 12 (80%) - using the mixer you can go to > 100%. I added it to the list. thanks for all the contribs! Brad ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ 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] btsco - a few comments and a small .py script 2005-08-20 20:13 ` Brad Midgley @ 2005-08-21 12:12 ` Andreas Beck 2005-08-21 19:26 ` Andreas Beck 1 sibling, 0 replies; 12+ messages in thread From: Andreas Beck @ 2005-08-21 12:12 UTC (permalink / raw) To: bluez-devel Hi Brad, > > I'd suggest to put a simple exaple there, how the results from > > "hciconfig hci0 revision" should look like. I.e. that the line > > "SCO mapping: HCI" should exist. > I cleaned this up a bit. Great. That should be clear now. > I don't know of such a command. /etc/bluetooth/link_key is how the keys > are stored in the older daemon so I've mentioned both in the docs. Yeah - this might as well help. > >3. I have written a small Python-Script and a .btscorc > Perfect. I gave a talk about btsco at our usergroup meeting and this > very question came up! (slides at http://flamebot.com/blog) > I will link to you or put these in a contrib dir (what do you think?) I don't care. I don't think this will need updates, unless the skype d-bus protocol gets changed in a fundamental way. So you might as well put it in a contrib dir. That makes it more obvious and readily available. License is PD as far as my part is concerned. It is derived from http://download.skype.com/share/devzone/example_linux.zip which does not have any copyright or license notes. However as it is a sample file from their API docs, I suppose this is not a problem. > >4. I also have the "microphone transmits noise" problem sometimes > > (rarely). Could it be, that there is a missed byte that swaps high > > and lowbyte? It sounded a bit like this to me. > I think you are right. There is some kind of fundamental transport glitch. If it gets annoying, I'll have a look at the btsco daemon and see if I can introduce a signal that will purposefully skip a single byte thus regaining sync (if my assumption is correct - I got to look at the code first or get a clue about the transmission format) if I have a noisy line. > >5. My cheap (EUR 22.- incl. VAT) LevelOne BLH-1000 Headset works fine, > > except for the glitch just described. It ignores microphone level > > setup, though. Loopback control works. Using the buttons, you can > > only reach Speaker Level 12 (80%) - using the mixer you can go to > > 100%. > I added it to the list. A nice addition for me would be a software mic-boost. The quality of the sound is not bad, but (probably due to the ridiculously compact design of my headset) the dynamic range is not used appropriately. I'll have a look, if I can add something like a "--micboost" switch that will just scale up the input before giving it to the sound device. Another thing I noticed (which is probably not btsco related, but more of a general bluez problem, maybe even a general kernel problem) is, that I now had two occasions where my USB subsystem became unresponsive to a point where the machine froze. I could still ping it, but mouse was unresponsive, and higher level network protocols had also stopped working. The syslogs say: Aug 19 00:34:58 cupido kernel: snd-bt-sco: setting playback to bspcm Aug 19 00:35:09 cupido kernel: uhci_hcd 0000:00:04.2: host system error, PCI problems? Aug 19 00:35:09 cupido kernel: uhci_hcd 0000:00:04.2: host controller halted, very bad! Aug 19 00:36:17 cupido kernel: snd-bt-sco: playback_trigger 0 Aug 19 00:36:17 cupido kernel: snd-bt-sco: setting playback to NULL Aug 19 00:36:17 cupido kernel: snd-bt-sco: capture_trigger 0 Aug 19 00:36:17 cupido kernel: snd-bt-sco: setting capture to NULL Aug 19 00:36:17 cupido kernel: snd-bt-sco: Disposing of previous socket count 2 Aug 19 00:36:59 cupido kernel: snd-bt-sco: playback_open Aug 19 00:36:59 cupido kernel: snd-bt-sco: capture_open Aug 19 00:36:59 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 672 count: 42 Aug 19 00:36:59 cupido kernel: snd-bt-sco: playback_trigger 1 Aug 19 00:36:59 cupido kernel: snd-bt-sco: setting playback to bspcm Aug 19 00:37:19 cupido kernel: snd-bt-sco: playback_trigger 0 Aug 19 00:37:19 cupido kernel: snd-bt-sco: setting playback to NULL Aug 19 00:38:01 cupido /USR/SBIN/CRON[8130]: (mail) CMD ( if [ -x /usr/lib/exim/exim3 -a -f /etc/exim/exim.conf ]; then /usr/lib/exim/exim3 -q ; fi) Aug 19 00:38:17 cupido kernel: hci_cmd_task: hci0 command tx timeout Aug 19 00:39:12 cupido kernel: usb 1-2: USB disconnect, address 2 Aug 19 00:39:12 cupido kernel: usb 1-2.3: USB disconnect, address 8 Aug 19 00:39:12 cupido kernel: usb 1-2.6: USB disconnect, address 13 Aug 19 00:39:41 cupido kernel: __tx_submit: hci0 tx submit failed urb f53cabf4 type 1 err -19 Aug 19 00:39:41 cupido kernel: __tx_submit: hci0 tx submit failed urb f53cabf4 type 1 err -19 [about 10 more similar messages] [at this point the system was still responsive to mouse/keyboard (PS/2 based) - I think I tried to reset the USB hub (Noname, called USB1007, Vendor 05e3, Product 0604, Revision 0.05) by pulling it's inbound plug, as it's link LEDs looked wrong (all off)] Aug 19 00:39:41 cupido hcid[7720]: HCI dev 0 down Aug 19 00:39:41 cupido hcid[7720]: Stoping security manager 0 Aug 19 00:39:42 cupido hcid[7720]: HCI dev 0 unregistered Aug 19 00:39:43 cupido kernel: usb 1-2: new full speed USB device using uhci_hcd and address 14 Aug 19 00:39:43 cupido kernel: hub 1-2:1.0: USB hub found Aug 19 00:39:43 cupido kernel: hub 1-2:1.0: 7 ports detected Aug 19 00:39:43 cupido kernel: usb 1-2.3: new full speed USB device using uhci_hcd and address 15 Aug 19 00:39:43 cupido kernel: drivers/usb/media/ov511.c: USB OV518 video device found Aug 19 00:39:43 cupido kernel: drivers/usb/media/ov511.c: Device revision 1 Aug 19 00:39:43 cupido kernel: drivers/usb/media/ov511.c: Compression required with OV518...enabling Aug 19 00:39:44 cupido usb.agent[8289]: ov511: already loaded Aug 19 00:39:45 cupido usb.agent[8322]: usbcore: already loaded Aug 19 00:39:45 cupido kernel: drivers/usb/media/ov511.c: Sensor is an OV6630AF Aug 19 00:39:46 cupido kernel: drivers/usb/media/ov511.c: Device at usb-0000:00:04.2-2.3 registered to minor 0 Aug 19 00:39:46 cupido kernel: usb 1-2.6: new full speed USB device using uhci_hcd and address 16 Aug 19 00:39:46 cupido kernel: Unable to load interpreter /lib/ld-linux.so.2 Aug 19 00:39:46 cupido kernel: Unable to handle kernel paging request at virtual address 000a7d02 Aug 19 00:39:46 cupido kernel: printing eip: Aug 19 00:39:46 cupido kernel: f88821e9 Aug 19 00:39:46 cupido kernel: *pde = 00000000 Aug 19 00:39:46 cupido kernel: Oops: 0000 [#1] Aug 19 00:39:46 cupido kernel: PREEMPT Aug 19 00:39:46 cupido kernel: Modules linked in: hci_usb sco tun rfcomm l2cap actisys_sir irtty_sir sir_dev irda crc_ccitt sg via_agp nls_iso8859_1 nls_cp437 vfat eth1394 w83781d i2c_sensor i2c_viapro i2c_core usb_storage msr microcode cpuid smbfs msdos fat video1394 raw1394 ohci1394 ieee1394 mga drm agpgart parport_pc lp parport snd_bt_sco snd_hwdep usbmouse ide_cd via82cxxx ide_core 8250_pci 8250 serial_core snd_ens1371 snd_rawmidi snd_ac97_codec snd_pcm_oss ov511 videodev snd_mixer_oss bluetooth snd_pcm snd_timer snd snd_page_alloc uhci_hcd usbcore evdev Aug 19 00:39:46 cupido kernel: CPU: 0 Aug 19 00:39:46 cupido kernel: EIP: 0060:[pg0+944181737/1069470720] Not tainted VLI Aug 19 00:39:46 cupido kernel: EFLAGS: 00010246 (2.6.12.5) Aug 19 00:39:46 cupido kernel: EIP is at usb_disable_interface+0x49/0x80 [usbcore] Aug 19 00:39:46 cupido kernel: eax: 00000000 ebx: eec94848 ecx: 00000282 edx: 000a7d00 Aug 19 00:39:46 cupido kernel: esi: 00000001 edi: eb595000 ebp: eec94880 esp: f70abd74 Aug 19 00:39:46 cupido kernel: ds: 007b es: 007b ss: 0068 Aug 19 00:39:46 cupido kernel: Process khubd (pid: 1138, threadinfo=f70aa000 task=f70425e0) Aug 19 00:39:46 cupido kernel: Stack: 0000000b 0000000b 00000000 eb595000 00000001 f8882533 eb595000 ea4c00a0 Aug 19 00:39:46 cupido kernel: 0000000b 00000001 00000002 00000001 00000000 00000000 00001388 ea4c00a0 Aug 19 00:39:46 cupido kernel: f88a5ec0 ea4c0ba0 00000002 eb595000 f88a4c09 eb595000 00000001 00000002 Aug 19 00:39:46 cupido kernel: Call Trace: Aug 19 00:39:46 cupido usb.agent[8388]: hci_usb: already loaded Aug 19 00:39:47 cupido kernel: [pg0+944182579/1069470720] usb_set_interface+0xe3/0x190 [usbcore] Aug 19 00:39:47 cupido kernel: [pg0+944323593/1069470720] hci_usb_probe+0x4a9/0x5e0 [hci_usb] Aug 19 00:39:47 cupido kernel: [new_inode+36/176] new_inode+0x24/0xb0 Aug 19 00:39:47 cupido kernel: [sysfs_new_dirent+41/128] sysfs_new_dirent+0x29/0x80 Aug 19 00:39:47 cupido kernel: [pg0+944148612/1069470720] usb_probe_interface+0x64/0x80 [usbcore] Aug 19 00:39:47 cupido kernel: [driver_probe_device+47/128] driver_probe_device+0x2f/0x80 Aug 19 00:39:47 cupido kernel: [device_attach+123/208] device_attach+0x7b/0xd0 Aug 19 00:39:47 cupido kernel: [kobject_get+23/32] kobject_get+0x17/0x20 Aug 19 00:39:47 cupido kernel: [bus_add_device+95/208] bus_add_device+0x5f/0xd0 Aug 19 00:39:47 cupido kernel: [device_pm_add+85/144] device_pm_add+0x55/0x90 Aug 19 00:39:47 cupido kernel: [device_add+232/384] device_add+0xe8/0x180 Aug 19 00:39:47 cupido kernel: [pg0+944183698/1069470720] usb_set_configuration+0x262/0x560 [usbcore] Aug 19 00:39:47 cupido kernel: [pg0+944159474/1069470720] usb_new_device+0x142/0x1e0 [usbcore] Aug 19 00:39:47 cupido kernel: [pg0+944163887/1069470720] hub_port_connect_change+0x36f/0x430 [usbcore] Aug 19 00:39:47 cupido kernel: [pg0+944164761/1069470720] hub_events+0x2a9/0x440 [usbcore] Aug 19 00:39:47 cupido kernel: [pg0+944165247/1069470720] hub_thread+0x4f/0x110 [usbcore] Aug 19 00:39:47 cupido kernel: [autoremove_wake_function+0/96] autoremove_wake_function+0x0/0x60 Aug 19 00:39:47 cupido kernel: [pg0+944165168/1069470720] hub_thread+0x0/0x110 [usbcore] Aug 19 00:39:47 cupido kernel: [kernel_thread_helper+5/12] kernel_thread_helper+0x5/0xc Aug 19 00:39:47 cupido kernel: Code: 75 10 8b 5c 24 08 8b 74 24 0c 8b 7c 24 10 83 c4 14 c3 31 f6 8d b4 26 00 00 00 00 8d bc 27 00 00 00 00 8b 53 0c 89 f0 46 c1 e0 05 <0f> b6 44 10 02 89 3c 24 89 44 24 04 e8 36 ff ff ff 0f b6 43 04 Aug 19 00:40:41 cupido sdpd[7722]: terminating... Aug 19 00:40:42 cupido hcid[8451]: Bluetooth HCI daemon Aug 19 00:40:42 cupido sdpd[8453]: Bluetooth SDP daemon Aug 19 00:41:32 cupido kernel: <6>usbcore: deregistering driver hci_usb Aug 19 00:43:08 cupido kernel: usbcore: deregistering driver ov511 Aug 19 00:43:52 cupido modprobe: FATAL: Error running install command for sound_slot_2 Aug 19 00:43:52 cupido modprobe: FATAL: Error running install command for sound_slot_2 Aug 19 00:48:02 cupido kernel: mtrr: no MTRR for e2000000,1000000 found Aug 19 00:48:02 cupido gdm[4128]: gdm_slave_xioerror_handler: Fatal X error - Restarting :0 Aug 19 00:48:05 cupido kernel: mtrr: no MTRR for e2000000,1000000 found Aug 19 00:48:06 cupido kernel: atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be trying access hardware directly. Aug 19 00:48:06 cupido kernel: atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be trying access hardware directly. Aug 19 00:48:23 cupido gconfd (becka-www-5389): GConf server is not in use, shutting down. Aug 19 00:48:23 cupido gconfd (becka-www-5389): Exiting Aug 19 00:48:23 cupido shutdown[8537]: shutting down for system reboot Aug 19 00:48:24 cupido init: Switching to runlevel: 6 Aug 19 00:48:27 cupido irattach: got SIGTERM or SIGINT Aug 19 00:48:27 cupido irattach: exiting ... Aug 19 00:48:27 cupido kernel: sirdev_put_instance Aug 19 00:48:27 cupido kernel: irtty_close - ttyS1: irda line discipline closed Aug 19 00:48:28 cupido ovpn-client[5651]: event_wait : Interrupted system call (code=4) Aug 19 00:48:28 cupido ovpn-client[5651]: TCP/UDP: Closing socket Aug 19 00:48:28 cupido ovpn-client[5651]: /sbin/route del -net 192.168.111.0 netmask 255.255.255.0 Aug 19 00:48:28 cupido ovpn-client[5651]: ERROR: Linux route delete command failed: shell command exited with error status: 7 Aug 19 00:48:28 cupido ovpn-client[5651]: /sbin/route del -net 192.168.112.0 netmask 255.255.255.0 Aug 19 00:48:28 cupido ovpn-client[5651]: ERROR: Linux route delete command failed: shell command exited with error status: 7 Aug 19 00:48:28 cupido ovpn-client[5651]: Closing TUN/TAP interface Aug 19 00:48:29 cupido ovpn-client[5651]: SIGTERM[hard,] received, process exiting Aug 19 00:48:29 cupido xfs[3884]: terminating Aug 19 00:48:30 cupido ntpd[4026]: ntpd exiting on signal 15 Aug 19 01:08:33 cupido syslogd 1.4.1#17: restart. On another occasion, it went down more drastically: Aug 19 21:51:08 cupido kernel: snd-bt-sco: playback_open Aug 19 21:51:08 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 cou Aug 19 21:51:08 cupido kernel: snd-bt-sco: playback_trigger 1 Aug 19 21:51:08 cupido kernel: snd-bt-sco: setting playback to bspcm Aug 19 21:59:52 cupido syslogd 1.4.1#17: restart. However before that happened, I see a few occurences of hci_scodata_packet: hci0 SCO packet for unknown connection handle [varies] and a bit later: snd-bt-sco: Disposing of previous socket count 3 snd-bt-sco: file_count is 1 (expected 3) shortly before it went down, I got: Aug 19 21:50:33 cupido kernel: hub 1-2:1.0: port 6 disabled by hub (EMI?), re-enabling... Aug 19 21:50:33 cupido kernel: usb 1-2.6: USB disconnect, address 10 Aug 19 21:50:33 cupido kernel: __tx_submit: hci0 tx submit failed urb f46d5214 type 3 err -19 Aug 19 21:50:33 cupido kernel: __tx_submit: hci0 tx submit failed urb f46d5214 type 3 err -19 Aug 19 21:50:33 cupido hcid[4121]: HCI dev 0 down Aug 19 21:50:33 cupido hcid[4121]: Stoping security manager 0 Aug 19 21:50:33 cupido kernel: snd-bt-sco: playback_trigger 1 Aug 19 21:50:33 cupido kernel: snd-bt-sco: setting playback to bspcm Aug 19 21:50:33 cupido hcid[4121]: HCI dev 0 unregistered Aug 19 21:50:34 cupido kernel: usb 1-2.6: new full speed USB device using uhci_hcd and address 11 Aug 19 21:50:34 cupido kernel: usb 1-2.6: device descriptor read/64, error -71 Aug 19 21:50:34 cupido kernel: usb 1-2.6: device descriptor read/64, error -71 Aug 19 21:50:34 cupido kernel: usb 1-2.6: new full speed USB device using uhci_hcd and address 12 Aug 19 21:50:34 cupido kernel: usb 1-2.6: device descriptor read/64, error -71 Aug 19 21:50:34 cupido kernel: usb 1-2.6: device descriptor read/64, error -71 Aug 19 21:50:34 cupido kernel: usb 1-2.6: new full speed USB device using uhci_hcd and address 13 Aug 19 21:50:35 cupido kernel: usb 1-2.6: device not accepting address 13, error -71 Aug 19 21:50:35 cupido kernel: usb 1-2.6: new full speed USB device using uhci_hcd and address 14 Aug 19 21:50:35 cupido kernel: usb 1-2.6: device not accepting address 14, error -71 Aug 19 21:50:37 cupido kernel: usb 1-2.6: new full speed USB device using uhci_hcd and address 15 Aug 19 21:50:38 cupido hcid[4121]: HCI dev 0 registered Aug 19 21:50:38 cupido usb.agent[26062]: hci_usb: already loaded Aug 19 21:50:38 cupido hcid[4121]: HCI dev 0 up Aug 19 21:50:38 cupido usb.agent[26105]: hci_usb: already loaded Aug 19 21:50:38 cupido hcid[4121]: Starting security manager 0 Aug 19 21:50:38 cupido usb.agent[26122]: hci_usb: already loaded Aug 19 21:50:41 cupido kernel: snd-bt-sco: playback_trigger 0 Aug 19 21:50:41 cupido kernel: snd-bt-sco: setting playback to NULL Aug 19 21:50:41 cupido kernel: snd-bt-sco: playback_open Aug 19 21:50:41 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 count: 800 Aug 19 21:50:41 cupido kernel: snd-bt-sco: playback_trigger 1 Aug 19 21:50:41 cupido kernel: snd-bt-sco: setting playback to bspcm Aug 19 21:50:45 cupido kernel: snd-bt-sco: playback_trigger 0 Aug 19 21:50:45 cupido kernel: snd-bt-sco: setting playback to NULL Aug 19 21:50:45 cupido kernel: snd-bt-sco: playback_open Aug 19 21:50:45 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 count: 800 Aug 19 21:50:45 cupido kernel: snd-bt-sco: playback_trigger 1 Aug 19 21:50:45 cupido kernel: snd-bt-sco: setting playback to bspcm Aug 19 21:50:46 cupido kernel: snd-bt-sco: playback_trigger 0 Aug 19 21:50:46 cupido kernel: snd-bt-sco: setting playback to NULL Aug 19 21:50:46 cupido kernel: snd-bt-sco: playback_open Aug 19 21:50:46 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 count: 800 Aug 19 21:50:46 cupido kernel: snd-bt-sco: playback_trigger 1 Aug 19 21:50:46 cupido kernel: snd-bt-sco: setting playback to bspcm Aug 19 21:50:49 cupido kernel: snd-bt-sco: playback_trigger 0 Aug 19 21:50:49 cupido kernel: snd-bt-sco: setting playback to NULL Aug 19 21:50:49 cupido kernel: snd-bt-sco: playback_open Aug 19 21:50:49 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 count: 800 Aug 19 21:50:49 cupido kernel: snd-bt-sco: playback_trigger 1 Aug 19 21:50:49 cupido kernel: snd-bt-sco: setting playback to bspcm Aug 19 21:50:51 cupido kernel: snd-bt-sco: playback_trigger 0 Aug 19 21:50:51 cupido kernel: snd-bt-sco: setting playback to NULL Aug 19 21:50:51 cupido kernel: snd-bt-sco: playback_open Aug 19 21:50:51 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 count: 800 Aug 19 21:50:51 cupido kernel: snd-bt-sco: playback_trigger 1 Aug 19 21:50:51 cupido kernel: snd-bt-sco: setting playback to bspcm Aug 19 21:50:56 cupido kernel: snd-bt-sco: playback_trigger 0 Aug 19 21:50:56 cupido kernel: snd-bt-sco: setting playback to NULL Aug 19 21:50:56 cupido kernel: snd-bt-sco: playback_open Aug 19 21:50:56 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 count: 800 Aug 19 21:50:56 cupido kernel: snd-bt-sco: playback_trigger 1 Aug 19 21:50:56 cupido kernel: snd-bt-sco: setting playback to bspcm Aug 19 21:50:57 cupido kernel: snd-bt-sco: playback_trigger 0 Aug 19 21:50:57 cupido kernel: snd-bt-sco: setting playback to NULL Aug 19 21:50:58 cupido kernel: snd-bt-sco: playback_open Aug 19 21:50:58 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 count: 800 Aug 19 21:50:58 cupido kernel: snd-bt-sco: playback_trigger 1 Aug 19 21:50:58 cupido kernel: snd-bt-sco: setting playback to bspcm Aug 19 21:51:02 cupido hcid[4121]: link_key_request (sba=00:09:DD:10:4E:8C, dba=00:0A:94:93:74:B7) Aug 19 21:51:08 cupido kernel: snd-bt-sco: playback_trigger 0 Aug 19 21:51:08 cupido kernel: snd-bt-sco: setting playback to NULL Aug 19 21:51:08 cupido kernel: snd-bt-sco: playback_open Aug 19 21:51:08 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 count: 800 Aug 19 21:51:08 cupido kernel: snd-bt-sco: playback_trigger 1 Aug 19 21:51:08 cupido kernel: snd-bt-sco: setting playback to bspcm Aug 19 21:59:52 cupido syslogd 1.4.1#17: restart. I'm not sure, what that means. It seems to be related to the USB Hub, which also usually shows erratic LED Link display when that happens. However I haven't seen this before using the BT dongle, and I was using it for a webcam before, so it shouldn't be related just to the larger amounts of traffic. I have also noticed my system hanging on shutdown when trying to unload the rfcomm stuff. This is usually cured by resetting the USB hub. This looks like this: Aug 21 04:12:14 cupido xfs[3928]: terminating Aug 21 04:12:15 cupido ntpd[4072]: ntpd exiting on signal 15 Aug 21 04:13:24 cupido kernel: usb 1-2: USB disconnect, address 2 Aug 21 04:13:24 cupido kernel: usb 1-2.3: USB disconnect, address 3 Aug 21 04:13:24 cupido kernel: usb 1-2.6: USB disconnect, address 4 Aug 21 04:13:26 cupido kernel: 1-2.6: usbfs: USBDEVFS_CONTROL failed cmd hid2hci rqt 64 rq 0 len 0 ret -110 Aug 21 04:13:26 cupido sdpd[4103]: terminating... Aug 21 04:13:26 cupido rpc.statd[4057]: Caught signal 15, un-registering and exiting. CU, ANdy ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ 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] btsco - a few comments and a small .py script 2005-08-20 20:13 ` Brad Midgley 2005-08-21 12:12 ` Andreas Beck @ 2005-08-21 19:26 ` Andreas Beck 2005-08-22 4:29 ` Brad Midgley 1 sibling, 1 reply; 12+ messages in thread From: Andreas Beck @ 2005-08-21 19:26 UTC (permalink / raw) To: bluez-devel [-- Attachment #1: Type: text/plain, Size: 20175 bytes --] [had to resend that, as I forgot to use the right source address, sorry. Thus a few comments I make now in [] ] Hi Brad, > > I'd suggest to put a simple exaple there, how the results from > > "hciconfig hci0 revision" should look like. I.e. that the line > > "SCO mapping: HCI" should exist. > I cleaned this up a bit. Great. That should be clear now. > I don't know of such a command. /etc/bluetooth/link_key is how the keys > are stored in the older daemon so I've mentioned both in the docs. Yeah - this might as well help. > >3. I have written a small Python-Script and a .btscorc > Perfect. I gave a talk about btsco at our usergroup meeting and this > very question came up! (slides at http://flamebot.com/blog) > I will link to you or put these in a contrib dir (what do you think?) I don't care. I don't think this will need updates, unless the skype d-bus protocol gets changed in a fundamental way. So you might as well put it in a contrib dir. That makes it more obvious and readily available. License is PD as far as my part is concerned. It is derived from http://download.skype.com/share/devzone/example_linux.zip which does not have any copyright or license notes. However as it is a sample file from their API docs, I suppose this is not a problem. > >4. I also have the "microphone transmits noise" problem sometimes > > (rarely). Could it be, that there is a missed byte that swaps high > > and lowbyte? It sounded a bit like this to me. > I think you are right. There is some kind of fundamental transport glitch. If it gets annoying, I'll have a look at the btsco daemon and see if I can introduce a signal that will purposefully skip a single byte thus regaining sync (if my assumption is correct - I got to look at the code first or get a clue about the transmission format) if I have a noisy line. [I just noticed, that the copying around is done in kernelspace. Got to check it there, then.] > >5. My cheap (EUR 22.- incl. VAT) LevelOne BLH-1000 Headset works fine, > > except for the glitch just described. It ignores microphone level > > setup, though. Loopback control works. Using the buttons, you can > > only reach Speaker Level 12 (80%) - using the mixer you can go to > > 100%. > I added it to the list. A nice addition for me would be a software mic-boost. The quality of the sound is not bad, but (probably due to the ridiculously compact design of my headset) the dynamic range is not used appropriately. I'll have a look, if I can add something like a "--micboost" switch that will just scale up the input before giving it to the sound device. [ I have in the meantime done this - crude patch attached. Only use if you know what it does and what you are doing. It cures my problem, but it's of course ugly. What do you think about adding a third Mixer bar like "Mic Softboost" which will allow to adjust a value by which the mic data gets scaled between about *0.1 and *10.0? This would allow for better usability for devices that ignore the mic setup sequences when used with software that doesn't scale by itself. If someone feels like implementing it, it might as well be a good idea to provide some kind of dynamic compression? ] Another thing I noticed (which is probably not btsco related, but more of a general bluez problem, maybe even a general kernel problem) is, that I now had two occasions where my USB subsystem became unresponsive to a point where the machine froze. I could still ping it, but mouse was unresponsive, and higher level network protocols had also stopped working. The syslogs say: Aug 19 00:34:58 cupido kernel: snd-bt-sco: setting playback to bspcm Aug 19 00:35:09 cupido kernel: uhci_hcd 0000:00:04.2: host system error, PCI problems? Aug 19 00:35:09 cupido kernel: uhci_hcd 0000:00:04.2: host controller halted, very bad! Aug 19 00:36:17 cupido kernel: snd-bt-sco: playback_trigger 0 Aug 19 00:36:17 cupido kernel: snd-bt-sco: setting playback to NULL Aug 19 00:36:17 cupido kernel: snd-bt-sco: capture_trigger 0 Aug 19 00:36:17 cupido kernel: snd-bt-sco: setting capture to NULL Aug 19 00:36:17 cupido kernel: snd-bt-sco: Disposing of previous socket count 2 Aug 19 00:36:59 cupido kernel: snd-bt-sco: playback_open Aug 19 00:36:59 cupido kernel: snd-bt-sco: capture_open Aug 19 00:36:59 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 672 count: 42 Aug 19 00:36:59 cupido kernel: snd-bt-sco: playback_trigger 1 Aug 19 00:36:59 cupido kernel: snd-bt-sco: setting playback to bspcm Aug 19 00:37:19 cupido kernel: snd-bt-sco: playback_trigger 0 Aug 19 00:37:19 cupido kernel: snd-bt-sco: setting playback to NULL Aug 19 00:38:01 cupido /USR/SBIN/CRON[8130]: (mail) CMD ( if [ -x /usr/lib/exim/exim3 -a -f /etc/exim/exim.conf ]; then /usr/lib/exim/exim3 -q ; fi) Aug 19 00:38:17 cupido kernel: hci_cmd_task: hci0 command tx timeout Aug 19 00:39:12 cupido kernel: usb 1-2: USB disconnect, address 2 Aug 19 00:39:12 cupido kernel: usb 1-2.3: USB disconnect, address 8 Aug 19 00:39:12 cupido kernel: usb 1-2.6: USB disconnect, address 13 Aug 19 00:39:41 cupido kernel: __tx_submit: hci0 tx submit failed urb f53cabf4 type 1 err -19 Aug 19 00:39:41 cupido kernel: __tx_submit: hci0 tx submit failed urb f53cabf4 type 1 err -19 [about 10 more similar messages] [at this point the system was still responsive to mouse/keyboard (PS/2 based) - I think I tried to reset the USB hub (Noname, called USB1007, Vendor 05e3, Product 0604, Revision 0.05) by pulling it's inbound plug, as it's link LEDs looked wrong (all off)] Aug 19 00:39:41 cupido hcid[7720]: HCI dev 0 down Aug 19 00:39:41 cupido hcid[7720]: Stoping security manager 0 Aug 19 00:39:42 cupido hcid[7720]: HCI dev 0 unregistered Aug 19 00:39:43 cupido kernel: usb 1-2: new full speed USB device using uhci_hcd and address 14 Aug 19 00:39:43 cupido kernel: hub 1-2:1.0: USB hub found Aug 19 00:39:43 cupido kernel: hub 1-2:1.0: 7 ports detected Aug 19 00:39:43 cupido kernel: usb 1-2.3: new full speed USB device using uhci_hcd and address 15 Aug 19 00:39:43 cupido kernel: drivers/usb/media/ov511.c: USB OV518 video device found Aug 19 00:39:43 cupido kernel: drivers/usb/media/ov511.c: Device revision 1 Aug 19 00:39:43 cupido kernel: drivers/usb/media/ov511.c: Compression required with OV518...enabling Aug 19 00:39:44 cupido usb.agent[8289]: ov511: already loaded Aug 19 00:39:45 cupido usb.agent[8322]: usbcore: already loaded Aug 19 00:39:45 cupido kernel: drivers/usb/media/ov511.c: Sensor is an OV6630AF Aug 19 00:39:46 cupido kernel: drivers/usb/media/ov511.c: Device at usb-0000:00:04.2-2.3 registered to minor 0 Aug 19 00:39:46 cupido kernel: usb 1-2.6: new full speed USB device using uhci_hcd and address 16 Aug 19 00:39:46 cupido kernel: Unable to load interpreter /lib/ld-linux.so.2 Aug 19 00:39:46 cupido kernel: Unable to handle kernel paging request at virtual address 000a7d02 Aug 19 00:39:46 cupido kernel: printing eip: Aug 19 00:39:46 cupido kernel: f88821e9 Aug 19 00:39:46 cupido kernel: *pde = 00000000 Aug 19 00:39:46 cupido kernel: Oops: 0000 [#1] Aug 19 00:39:46 cupido kernel: PREEMPT Aug 19 00:39:46 cupido kernel: Modules linked in: hci_usb sco tun rfcomm l2cap actisys_sir irtty_sir sir_dev irda crc_ccitt sg via_agp nls_iso8859_1 nls_cp437 vfat eth1394 w83781d i2c_sensor i2c_viapro i2c_core usb_storage msr microcode cpuid smbfs msdos fat video1394 raw1394 ohci1394 ieee1394 mga drm agpgart parport_pc lp parport snd_bt_sco snd_hwdep usbmouse ide_cd via82cxxx ide_core 8250_pci 8250 serial_core snd_ens1371 snd_rawmidi snd_ac97_codec snd_pcm_oss ov511 videodev snd_mixer_oss bluetooth snd_pcm snd_timer snd snd_page_alloc uhci_hcd usbcore evdev Aug 19 00:39:46 cupido kernel: CPU: 0 Aug 19 00:39:46 cupido kernel: EIP: 0060:[pg0+944181737/1069470720] Not tainted VLI Aug 19 00:39:46 cupido kernel: EFLAGS: 00010246 (2.6.12.5) Aug 19 00:39:46 cupido kernel: EIP is at usb_disable_interface+0x49/0x80 [usbcore] Aug 19 00:39:46 cupido kernel: eax: 00000000 ebx: eec94848 ecx: 00000282 edx: 000a7d00 Aug 19 00:39:46 cupido kernel: esi: 00000001 edi: eb595000 ebp: eec94880 esp: f70abd74 Aug 19 00:39:46 cupido kernel: ds: 007b es: 007b ss: 0068 Aug 19 00:39:46 cupido kernel: Process khubd (pid: 1138, threadinfo=f70aa000 task=f70425e0) Aug 19 00:39:46 cupido kernel: Stack: 0000000b 0000000b 00000000 eb595000 00000001 f8882533 eb595000 ea4c00a0 Aug 19 00:39:46 cupido kernel: 0000000b 00000001 00000002 00000001 00000000 00000000 00001388 ea4c00a0 Aug 19 00:39:46 cupido kernel: f88a5ec0 ea4c0ba0 00000002 eb595000 f88a4c09 eb595000 00000001 00000002 Aug 19 00:39:46 cupido kernel: Call Trace: Aug 19 00:39:46 cupido usb.agent[8388]: hci_usb: already loaded Aug 19 00:39:47 cupido kernel: [pg0+944182579/1069470720] usb_set_interface+0xe3/0x190 [usbcore] Aug 19 00:39:47 cupido kernel: [pg0+944323593/1069470720] hci_usb_probe+0x4a9/0x5e0 [hci_usb] Aug 19 00:39:47 cupido kernel: [new_inode+36/176] new_inode+0x24/0xb0 Aug 19 00:39:47 cupido kernel: [sysfs_new_dirent+41/128] sysfs_new_dirent+0x29/0x80 Aug 19 00:39:47 cupido kernel: [pg0+944148612/1069470720] usb_probe_interface+0x64/0x80 [usbcore] Aug 19 00:39:47 cupido kernel: [driver_probe_device+47/128] driver_probe_device+0x2f/0x80 Aug 19 00:39:47 cupido kernel: [device_attach+123/208] device_attach+0x7b/0xd0 Aug 19 00:39:47 cupido kernel: [kobject_get+23/32] kobject_get+0x17/0x20 Aug 19 00:39:47 cupido kernel: [bus_add_device+95/208] bus_add_device+0x5f/0xd0 Aug 19 00:39:47 cupido kernel: [device_pm_add+85/144] device_pm_add+0x55/0x90 Aug 19 00:39:47 cupido kernel: [device_add+232/384] device_add+0xe8/0x180 Aug 19 00:39:47 cupido kernel: [pg0+944183698/1069470720] usb_set_configuration+0x262/0x560 [usbcore] Aug 19 00:39:47 cupido kernel: [pg0+944159474/1069470720] usb_new_device+0x142/0x1e0 [usbcore] Aug 19 00:39:47 cupido kernel: [pg0+944163887/1069470720] hub_port_connect_change+0x36f/0x430 [usbcore] Aug 19 00:39:47 cupido kernel: [pg0+944164761/1069470720] hub_events+0x2a9/0x440 [usbcore] Aug 19 00:39:47 cupido kernel: [pg0+944165247/1069470720] hub_thread+0x4f/0x110 [usbcore] Aug 19 00:39:47 cupido kernel: [autoremove_wake_function+0/96] autoremove_wake_function+0x0/0x60 Aug 19 00:39:47 cupido kernel: [pg0+944165168/1069470720] hub_thread+0x0/0x110 [usbcore] Aug 19 00:39:47 cupido kernel: [kernel_thread_helper+5/12] kernel_thread_helper+0x5/0xc Aug 19 00:39:47 cupido kernel: Code: 75 10 8b 5c 24 08 8b 74 24 0c 8b 7c 24 10 83 c4 14 c3 31 f6 8d b4 26 00 00 00 00 8d bc 27 00 00 00 00 8b 53 0c 89 f0 46 c1 e0 05 <0f> b6 44 10 02 89 3c 24 89 44 24 04 e8 36 ff ff ff 0f b6 43 04 Aug 19 00:40:41 cupido sdpd[7722]: terminating... Aug 19 00:40:42 cupido hcid[8451]: Bluetooth HCI daemon Aug 19 00:40:42 cupido sdpd[8453]: Bluetooth SDP daemon Aug 19 00:41:32 cupido kernel: <6>usbcore: deregistering driver hci_usb Aug 19 00:43:08 cupido kernel: usbcore: deregistering driver ov511 Aug 19 00:43:52 cupido modprobe: FATAL: Error running install command for sound_slot_2 Aug 19 00:43:52 cupido modprobe: FATAL: Error running install command for sound_slot_2 Aug 19 00:48:02 cupido kernel: mtrr: no MTRR for e2000000,1000000 found Aug 19 00:48:02 cupido gdm[4128]: gdm_slave_xioerror_handler: Fatal X error - Restarting :0 Aug 19 00:48:05 cupido kernel: mtrr: no MTRR for e2000000,1000000 found Aug 19 00:48:06 cupido kernel: atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be trying access hardware directly. Aug 19 00:48:06 cupido kernel: atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be trying access hardware directly. Aug 19 00:48:23 cupido gconfd (becka-www-5389): GConf server is not in use, shutting down. Aug 19 00:48:23 cupido gconfd (becka-www-5389): Exiting Aug 19 00:48:23 cupido shutdown[8537]: shutting down for system reboot Aug 19 00:48:24 cupido init: Switching to runlevel: 6 Aug 19 00:48:27 cupido irattach: got SIGTERM or SIGINT Aug 19 00:48:27 cupido irattach: exiting ... Aug 19 00:48:27 cupido kernel: sirdev_put_instance Aug 19 00:48:27 cupido kernel: irtty_close - ttyS1: irda line discipline closed Aug 19 00:48:28 cupido ovpn-client[5651]: event_wait : Interrupted system call (code=4) Aug 19 00:48:28 cupido ovpn-client[5651]: TCP/UDP: Closing socket Aug 19 00:48:28 cupido ovpn-client[5651]: /sbin/route del -net 192.168.111.0 netmask 255.255.255.0 Aug 19 00:48:28 cupido ovpn-client[5651]: ERROR: Linux route delete command failed: shell command exited with error status: 7 Aug 19 00:48:28 cupido ovpn-client[5651]: /sbin/route del -net 192.168.112.0 netmask 255.255.255.0 Aug 19 00:48:28 cupido ovpn-client[5651]: ERROR: Linux route delete command failed: shell command exited with error status: 7 Aug 19 00:48:28 cupido ovpn-client[5651]: Closing TUN/TAP interface Aug 19 00:48:29 cupido ovpn-client[5651]: SIGTERM[hard,] received, process exiting Aug 19 00:48:29 cupido xfs[3884]: terminating Aug 19 00:48:30 cupido ntpd[4026]: ntpd exiting on signal 15 Aug 19 01:08:33 cupido syslogd 1.4.1#17: restart. On another occasion, it went down more drastically: Aug 19 21:51:08 cupido kernel: snd-bt-sco: playback_open Aug 19 21:51:08 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 cou Aug 19 21:51:08 cupido kernel: snd-bt-sco: playback_trigger 1 Aug 19 21:51:08 cupido kernel: snd-bt-sco: setting playback to bspcm Aug 19 21:59:52 cupido syslogd 1.4.1#17: restart. However before that happened, I see a few occurences of hci_scodata_packet: hci0 SCO packet for unknown connection handle [varies] and a bit later: snd-bt-sco: Disposing of previous socket count 3 snd-bt-sco: file_count is 1 (expected 3) shortly before it went down, I got: Aug 19 21:50:33 cupido kernel: hub 1-2:1.0: port 6 disabled by hub (EMI?), re-enabling... Aug 19 21:50:33 cupido kernel: usb 1-2.6: USB disconnect, address 10 Aug 19 21:50:33 cupido kernel: __tx_submit: hci0 tx submit failed urb f46d5214 type 3 err -19 Aug 19 21:50:33 cupido kernel: __tx_submit: hci0 tx submit failed urb f46d5214 type 3 err -19 Aug 19 21:50:33 cupido hcid[4121]: HCI dev 0 down Aug 19 21:50:33 cupido hcid[4121]: Stoping security manager 0 Aug 19 21:50:33 cupido kernel: snd-bt-sco: playback_trigger 1 Aug 19 21:50:33 cupido kernel: snd-bt-sco: setting playback to bspcm Aug 19 21:50:33 cupido hcid[4121]: HCI dev 0 unregistered Aug 19 21:50:34 cupido kernel: usb 1-2.6: new full speed USB device using uhci_hcd and address 11 Aug 19 21:50:34 cupido kernel: usb 1-2.6: device descriptor read/64, error -71 Aug 19 21:50:34 cupido kernel: usb 1-2.6: device descriptor read/64, error -71 Aug 19 21:50:34 cupido kernel: usb 1-2.6: new full speed USB device using uhci_hcd and address 12 Aug 19 21:50:34 cupido kernel: usb 1-2.6: device descriptor read/64, error -71 Aug 19 21:50:34 cupido kernel: usb 1-2.6: device descriptor read/64, error -71 Aug 19 21:50:34 cupido kernel: usb 1-2.6: new full speed USB device using uhci_hcd and address 13 Aug 19 21:50:35 cupido kernel: usb 1-2.6: device not accepting address 13, error -71 Aug 19 21:50:35 cupido kernel: usb 1-2.6: new full speed USB device using uhci_hcd and address 14 Aug 19 21:50:35 cupido kernel: usb 1-2.6: device not accepting address 14, error -71 Aug 19 21:50:37 cupido kernel: usb 1-2.6: new full speed USB device using uhci_hcd and address 15 Aug 19 21:50:38 cupido hcid[4121]: HCI dev 0 registered Aug 19 21:50:38 cupido usb.agent[26062]: hci_usb: already loaded Aug 19 21:50:38 cupido hcid[4121]: HCI dev 0 up Aug 19 21:50:38 cupido usb.agent[26105]: hci_usb: already loaded Aug 19 21:50:38 cupido hcid[4121]: Starting security manager 0 Aug 19 21:50:38 cupido usb.agent[26122]: hci_usb: already loaded Aug 19 21:50:41 cupido kernel: snd-bt-sco: playback_trigger 0 Aug 19 21:50:41 cupido kernel: snd-bt-sco: setting playback to NULL Aug 19 21:50:41 cupido kernel: snd-bt-sco: playback_open Aug 19 21:50:41 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 count: 800 Aug 19 21:50:41 cupido kernel: snd-bt-sco: playback_trigger 1 Aug 19 21:50:41 cupido kernel: snd-bt-sco: setting playback to bspcm Aug 19 21:50:45 cupido kernel: snd-bt-sco: playback_trigger 0 Aug 19 21:50:45 cupido kernel: snd-bt-sco: setting playback to NULL Aug 19 21:50:45 cupido kernel: snd-bt-sco: playback_open Aug 19 21:50:45 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 count: 800 Aug 19 21:50:45 cupido kernel: snd-bt-sco: playback_trigger 1 Aug 19 21:50:45 cupido kernel: snd-bt-sco: setting playback to bspcm Aug 19 21:50:46 cupido kernel: snd-bt-sco: playback_trigger 0 Aug 19 21:50:46 cupido kernel: snd-bt-sco: setting playback to NULL Aug 19 21:50:46 cupido kernel: snd-bt-sco: playback_open Aug 19 21:50:46 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 count: 800 Aug 19 21:50:46 cupido kernel: snd-bt-sco: playback_trigger 1 Aug 19 21:50:46 cupido kernel: snd-bt-sco: setting playback to bspcm Aug 19 21:50:49 cupido kernel: snd-bt-sco: playback_trigger 0 Aug 19 21:50:49 cupido kernel: snd-bt-sco: setting playback to NULL Aug 19 21:50:49 cupido kernel: snd-bt-sco: playback_open Aug 19 21:50:49 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 count: 800 Aug 19 21:50:49 cupido kernel: snd-bt-sco: playback_trigger 1 Aug 19 21:50:49 cupido kernel: snd-bt-sco: setting playback to bspcm Aug 19 21:50:51 cupido kernel: snd-bt-sco: playback_trigger 0 Aug 19 21:50:51 cupido kernel: snd-bt-sco: setting playback to NULL Aug 19 21:50:51 cupido kernel: snd-bt-sco: playback_open Aug 19 21:50:51 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 count: 800 Aug 19 21:50:51 cupido kernel: snd-bt-sco: playback_trigger 1 Aug 19 21:50:51 cupido kernel: snd-bt-sco: setting playback to bspcm Aug 19 21:50:56 cupido kernel: snd-bt-sco: playback_trigger 0 Aug 19 21:50:56 cupido kernel: snd-bt-sco: setting playback to NULL Aug 19 21:50:56 cupido kernel: snd-bt-sco: playback_open Aug 19 21:50:56 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 count: 800 Aug 19 21:50:56 cupido kernel: snd-bt-sco: playback_trigger 1 Aug 19 21:50:56 cupido kernel: snd-bt-sco: setting playback to bspcm Aug 19 21:50:57 cupido kernel: snd-bt-sco: playback_trigger 0 Aug 19 21:50:57 cupido kernel: snd-bt-sco: setting playback to NULL Aug 19 21:50:58 cupido kernel: snd-bt-sco: playback_open Aug 19 21:50:58 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 count: 800 Aug 19 21:50:58 cupido kernel: snd-bt-sco: playback_trigger 1 Aug 19 21:50:58 cupido kernel: snd-bt-sco: setting playback to bspcm Aug 19 21:51:02 cupido hcid[4121]: link_key_request (sba=00:09:DD:10:4E:8C, dba=00:0A:94:93:74:B7) Aug 19 21:51:08 cupido kernel: snd-bt-sco: playback_trigger 0 Aug 19 21:51:08 cupido kernel: snd-bt-sco: setting playback to NULL Aug 19 21:51:08 cupido kernel: snd-bt-sco: playback_open Aug 19 21:51:08 cupido kernel: snd-bt-sco: prepare ok bps: 16000 size: 8000 count: 800 Aug 19 21:51:08 cupido kernel: snd-bt-sco: playback_trigger 1 Aug 19 21:51:08 cupido kernel: snd-bt-sco: setting playback to bspcm Aug 19 21:59:52 cupido syslogd 1.4.1#17: restart. I'm not sure, what that means. It seems to be related to the USB Hub, which also usually shows erratic LED Link display when that happens. However I haven't seen this before using the BT dongle, and I was using it for a webcam before, so it shouldn't be related just to the larger amounts of traffic. I have also noticed my system hanging on shutdown when trying to unload the rfcomm stuff. This is usually cured by resetting the USB hub. This looks like this: Aug 21 04:12:14 cupido xfs[3928]: terminating Aug 21 04:12:15 cupido ntpd[4072]: ntpd exiting on signal 15 Aug 21 04:13:24 cupido kernel: usb 1-2: USB disconnect, address 2 Aug 21 04:13:24 cupido kernel: usb 1-2.3: USB disconnect, address 3 Aug 21 04:13:24 cupido kernel: usb 1-2.6: USB disconnect, address 4 Aug 21 04:13:26 cupido kernel: 1-2.6: usbfs: USBDEVFS_CONTROL failed cmd hid2hci rqt 64 rq 0 len 0 ret -110 Aug 21 04:13:26 cupido sdpd[4103]: terminating... Aug 21 04:13:26 cupido rpc.statd[4057]: Caught signal 15, un-registering and exiting. CU, ANdy [-- Attachment #2: btsco.diff --] [-- Type: text/plain, Size: 764 bytes --] Index: btsco.c =================================================================== RCS file: /cvsroot/bluetooth-alsa/btsco/kernel/btsco.c,v retrieving revision 1.6 diff -c -r1.6 btsco.c *** btsco.c 19 Mar 2005 14:28:59 -0000 1.6 --- btsco.c 21 Aug 2005 19:23:16 -0000 *************** *** 790,795 **** --- 790,796 ---- struct msghdr msg; struct iovec iov; sigset_t unblocked; + int i; lock_kernel(); *************** *** 839,844 **** --- 840,851 ---- len = sock_recvmsg(sock, &msg, BUF_SIZE, 0); if (len > 0) { + for(i=0;i<len-1;i+=2) { + short int j=(buf[i]<<8)|buf[i+1]; + j*=4; + buf[i]=j>>8; + buf[i+1]=j&0xff; + } down(&bt_sco->capture_sem); if (bt_sco->capture) { snd_card_bt_sco_pcm_receive ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bluez-devel] btsco - a few comments and a small .py script 2005-08-21 19:26 ` Andreas Beck @ 2005-08-22 4:29 ` Brad Midgley 2005-08-22 12:09 ` Andreas Beck 0 siblings, 1 reply; 12+ messages in thread From: Brad Midgley @ 2005-08-22 4:29 UTC (permalink / raw) To: bluez-devel Andreas >>>3. I have written a small Python-Script and a .btscorc >> >>Perfect. I gave a talk about btsco at our usergroup meeting and this >>very question came up! (slides at http://flamebot.com/blog) >>I will link to you or put these in a contrib dir (what do you think?) > > > I don't care. I don't think this will need updates, unless the skype > d-bus protocol gets changed in a fundamental way. Ok, I will put it in contrib and add a note that it's derived from the api documentation example. If you like the mod from "Whoopie" I'll apply that too. > [I just noticed, that the copying around is done in kernelspace. Got to > check it there, then.] I'll bet we could watch for this. If byte order gets reversed, it might present a pattern that we can identify. It seems like SCO is not a reliable transport so maybe bluez is supposed to watch for this kind of stuff somehow. I should read up on it... > A nice addition for me would be a software mic-boost. The quality of the > sound is not bad, but (probably due to the ridiculously compact design > of my headset) the dynamic range is not used appropriately. The general solution is an adaptive boost which would be nice even for mics that use the full range. It's a common problem so I'll bet you can get this from one of the alsa layers in userspace. > Another thing I noticed (which is probably not btsco related, but more > of a general bluez problem, maybe even a general kernel problem) is, > that I now had two occasions where my USB subsystem became unresponsive > to a point where the machine froze. I suppose since it's only happened twice you can't reproduce it? I'm not much help looking over logs since I don't know what to look for. I've seen times where the mouse starts acting whacked and focus gets stuck on some widget even if the mouse is pointing elsewhere. I've been meaning to restart hidd and/or reload evdev to see if it's linked to the bluetooth mouse. Brad ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ 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] btsco - a few comments and a small .py script 2005-08-22 4:29 ` Brad Midgley @ 2005-08-22 12:09 ` Andreas Beck 2005-08-22 18:38 ` Andreas Beck 0 siblings, 1 reply; 12+ messages in thread From: Andreas Beck @ 2005-08-22 12:09 UTC (permalink / raw) To: bluez-devel Hi Brad, > >>>3. I have written a small Python-Script and a .btscorc > >>I will link to you or put these in a contrib dir (what do you think?) > >I don't care. I don't think this will need updates, unless the skype > >d-bus protocol gets changed in a fundamental way. > Ok, I will put it in contrib and add a note that it's derived from the > api documentation example. If you like the mod from "Whoopie" I'll apply > that too. Yeah. I like it. Much appreciated enhancement. I've uploaded his version to my site as well. I suggest you use this version. I made a minimal change to Whoopie's version. I call the API-Name "SkypePickup" which is probably more generic, as the script will do a pickup - it does not really have something to do with BT headsets, except that it is a nice sample application. > >[I just noticed, that the copying around is done in kernelspace. Got to > > check it there, then.] > I'll bet we could watch for this. If byte order gets reversed, it might > present a pattern that we can identify. Very probably. If there is a little noise on the line, the pattern for a signed16 signal will be, that there is an unusual amount of lowbytes being 0x00 or 0xff. My first idea would be to check, if _all_ lowbytes (i.e. the lowbytes as they are transmitted) are 0x00 or 0xff in a transmitted block of not too short length. If that is the case, I'd suggest to just "miss" a single byte in transfer. If that cures the problem, it should be ok. The only case where this doesn't work should be very noisy environments. I don't think it will mistrigger on natural inputs. > It seems like SCO is not a reliable transport so maybe bluez is > supposed to watch for this kind of stuff somehow. I should read > up on it... I had assumed it is reliable enough to send only even-length messages. But that might be not true. You might want to check that. > >A nice addition for me would be a software mic-boost. The quality of the > >sound is not bad, but (probably due to the ridiculously compact design > >of my headset) the dynamic range is not used appropriately. > The general solution is an adaptive boost which would be nice even for > mics that use the full range. It's a common problem so I'll bet you can > get this from one of the alsa layers in userspace. The main problem is, that I got to work without floating point stuff, as this goes into kernelspace and that I got to keep CPU usage low. But I think I can manage that. I used to do some realtime signal processing a while ago. > >Another thing I noticed (which is probably not btsco related, but more > >of a general bluez problem, maybe even a general kernel problem) is, > >that I now had two occasions where my USB subsystem became unresponsive > >to a point where the machine froze. > I suppose since it's only happened twice you can't reproduce it? No, not really. The shutdown-lockup seems to happen quite often, though. > I've seen times where the mouse starts acting whacked and focus gets > stuck on some widget even if the mouse is pointing elsewhere. I've been > meaning to restart hidd and/or reload evdev to see if it's linked to the > bluetooth mouse. This sounds more like a windowmanager problem. I've seen this with wired mice as well at times. Restarting the WM usually helps. CU, ANdy -- = Andreas Beck | Email : <becka-sig@bedatec.de> = ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ 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] btsco - a few comments and a small .py script 2005-08-22 12:09 ` Andreas Beck @ 2005-08-22 18:38 ` Andreas Beck 2005-08-22 18:53 ` [Bluez-devel] AGC and anti-noise patch for btsco kernel module Andreas Beck 0 siblings, 1 reply; 12+ messages in thread From: Andreas Beck @ 2005-08-22 18:38 UTC (permalink / raw) To: bluez-devel Andreas Beck <becka-bzdvl@bedatec.de> wrote: > > >[I just noticed, that the copying around is done in kernelspace. Got to > > > check it there, then.] > > I'll bet we could watch for this. If byte order gets reversed, it might > > present a pattern that we can identify. > Very probably. If there is a little noise on the line, the pattern for a > signed16 signal will be, that there is an unusual amount of > lowbytes being 0x00 or 0xff. That was right. I have a patch that fixes this. It basically checks, if all lowbytes are 0x00 or 0xff in a transmission block (which happens when there is silence, and the bytes are swapped). I also request that the block is at least 32 bytes long, but I suppose this always happens. I have only seen 48 byte blocks for my hardware. > > It seems like SCO is not a reliable transport so maybe bluez is > > supposed to watch for this kind of stuff somehow. I should read > > up on it... > I had assumed it is reliable enough to send only even-length messages. > But that might be not true. You might want to check that. It seems it is not an issue of variable length messages. I have put in a warning, if you get odd length packets, but it doesn't trigger for me, though I have the noise-problem occasionally. The above heuristic seems to fix it, though. For me, it happend once on the first connection after loading the module, usually. For this reason, my fixup code will trigger on the first and second connection now (fix the first, fall back to normal behaviour for the second). All connections are ok now. > > >A nice addition for me would be a software mic-boost. The quality of the > > >sound is not bad, but (probably due to the ridiculously compact design > > >of my headset) the dynamic range is not used appropriately. > > The general solution is an adaptive boost which would be nice even for > > mics that use the full range. It's a common problem so I'll bet you can > > get this from one of the alsa layers in userspace. > The main problem is, that I got to work without floating point stuff, > as this goes into kernelspace and that I got to keep CPU usage low. > But I think I can manage that. I used to do some realtime signal > processing a while ago. [x] Done. I added a new boolean mixer variable AGC that will turn on AGC. You may want to check if I did that right, and if it was really necessary to put in the put and get functions, or if alsa standard functions would have done. AGC is very simplistic, but works nicely for me: AGC ist limited to 1/16 - 20 times gain. It goes up by 1/16 for every 1/20 second that the signal (after processing) stays below an absolute value of 1000. This puts an upper limit to amplifying MIC noise. It goes down immediately ba 1/16 for every overshoot value detected. Works ok for me. > > I've seen times where the mouse starts acting whacked and focus gets > > stuck on some widget even if the mouse is pointing elsewhere. I've been > > meaning to restart hidd and/or reload evdev to see if it's linked to the > > bluetooth mouse. > This sounds more like a windowmanager problem. I've seen this with wired > mice as well at times. Restarting the WM usually helps. Very interesting. I got that one as well this afternoon. However keyboard was not working as well (maybe due to the stuck focus) So restarting fvwm didn't work. Killing from the console did. CU, ANdy -- = Andreas Beck | Email : <becka-sig@bedatec.de> = ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ 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
* [Bluez-devel] AGC and anti-noise patch for btsco kernel module 2005-08-22 18:38 ` Andreas Beck @ 2005-08-22 18:53 ` Andreas Beck 2005-08-22 22:10 ` Brad Midgley 0 siblings, 1 reply; 12+ messages in thread From: Andreas Beck @ 2005-08-22 18:53 UTC (permalink / raw) To: bluez-devel [-- Attachment #1: Type: text/plain, Size: 93 bytes --] Now for the patch (against CVS) described in the previous mail ... Have fun with it, Andy [-- Attachment #2: btsco.diff --] [-- Type: text/plain, Size: 5079 bytes --] Index: btsco.c =================================================================== RCS file: /cvsroot/bluetooth-alsa/btsco/kernel/btsco.c,v retrieving revision 1.6 diff -c -r1.6 btsco.c *** btsco.c 19 Mar 2005 14:28:59 -0000 1.6 --- btsco.c 22 Aug 2005 18:12:39 -0000 *************** *** 21,26 **** --- 21,33 ---- * */ + /* Autoadjust mic at most this often in 1/8000s */ + #define GRABSAMPLES 400 + /* Maximum push for the mike 16= 1:1 - default 20:1 = 320*/ + #define COMPRESSION_MAX_16 320 + /* Minimum push for the mike 1= 1:16*/ + #define COMPRESSION_MIN_16 1 + #define chip_t snd_card_bt_sco_t #include <sound/driver.h> *************** *** 93,100 **** snd_card_t *card; spinlock_t mixer_lock; int mixer_volume[MIXER_ADDR_LAST + 1]; ! snd_kcontrol_t *mixer_controls[MIXER_ADDR_LAST + 2]; /* also loopback */ volatile int loopback; atomic_t playback_count, capture_count; volatile int count_changed; spinlock_t count_changed_lock; --- 100,108 ---- snd_card_t *card; spinlock_t mixer_lock; int mixer_volume[MIXER_ADDR_LAST + 1]; ! snd_kcontrol_t *mixer_controls[MIXER_ADDR_LAST + 2 + 1]; /* also loopback and agc */ volatile int loopback; + volatile int agc; atomic_t playback_count, capture_count; volatile int count_changed; spinlock_t count_changed_lock; *************** *** 569,574 **** --- 577,611 ---- return changed; } + static int snd_bt_sco_agc_get(snd_kcontrol_t * kcontrol, + snd_ctl_elem_value_t * ucontrol) + { + snd_card_bt_sco_t *bt_sco = snd_kcontrol_chip(kcontrol); + unsigned long flags; + + spin_lock_irqsave(&bt_sco->mixer_lock, flags); + ucontrol->value.integer.value[0] = bt_sco->agc; + spin_unlock_irqrestore(&bt_sco->mixer_lock, flags); + return 0; + } + + static int snd_bt_sco_agc_put(snd_kcontrol_t * kcontrol, + snd_ctl_elem_value_t * ucontrol) + { + snd_card_bt_sco_t *bt_sco = snd_kcontrol_chip(kcontrol); + unsigned long flags; + int changed; + int agc; + + agc = !!ucontrol->value.integer.value[0]; + + spin_lock_irqsave(&bt_sco->mixer_lock, flags); + changed = bt_sco->agc != agc; + bt_sco->agc = agc; + spin_unlock_irqrestore(&bt_sco->mixer_lock, flags); + return changed; + } + #define BT_SCO_CONTROLS (sizeof(snd_bt_sco_controls)/sizeof(snd_kcontrol_new_t)) static snd_kcontrol_new_t snd_bt_sco_controls[] = { *************** *** 580,585 **** --- 617,629 ---- .info = snd_bt_sco_boolean_info, .get = snd_bt_sco_loopback_get, .put = snd_bt_sco_loopback_put, + }, + {.iface = SNDRV_CTL_ELEM_IFACE_MIXER, + .name = "AGC Switch", + .index = 0, + .info = snd_bt_sco_boolean_info, + .get = snd_bt_sco_agc_get, + .put = snd_bt_sco_agc_put, } }; *************** *** 790,795 **** --- 834,844 ---- struct msghdr msg; struct iovec iov; sigset_t unblocked; + int i; + static int factor=16; + static int maxvalsmoothed=0; + static int maxvalgrablen=GRABSAMPLES; /* adjust volume at most 4 times/second */ + static int swap=0; lock_kernel(); *************** *** 839,844 **** --- 888,954 ---- len = sock_recvmsg(sock, &msg, BUF_SIZE, 0); if (len > 0) { + int lostatcnt; + + lostatcnt=0; + if (len&1) dprintk("odd len %d\n",len); + for(i=0;i<len-1;i+=2) { + short int j; + int k; + + if (swap) j=(buf[i]<<8)|buf[i+1]; + else j=(buf[i+1]<<8)|buf[i]; + + /* occasionally the Headset will loose a byte + * on startup. Thus swapping lo/hi. + * counting, if _all_ lo bytes (which are + * actually high bytes) are 0 or -1 + * will detect this with a very high probability + */ + if ((j&0xff)==0||(j&0xff)==0xff) { + lostatcnt++; + } + /* scale the mic input - we do some kind + * of dynamics compression + */ + k=((int)j*factor)/16; + /* clip overshoot. Better than just letting + * it wrap around. Immediately adjust factor. + */ + if (k>0x7fff) { + k=0x7fff; + if (bt_sco->agc&&factor>COMPRESSION_MIN_16) factor--; + } else if (k<-0x8000) { + k=0x8000; + if (bt_sco->agc&&factor>COMPRESSION_MIN_16) factor--; + } + buf[i+1]=(k>>8)&0xff; + buf[i ]=k&0xff; + /* find the highest absolute value in a + * GRABSAMPLES long interval. + */ + if (k<0) k=-j; + if (k>maxvalsmoothed) maxvalsmoothed=k; + /* if the interval is over, recalculate + * the compression factor. Move it slowly. + */ + if (maxvalgrablen--<=0) { + maxvalgrablen=GRABSAMPLES; + /* If the noise goes up over 1000, we stop + * pushing the software gain + */ + if (maxvalsmoothed<1000&&factor<COMPRESSION_MAX_16) { + factor++; + // dprintk("Up to %d\n",factor); + } + if (!bt_sco->agc) factor=16; + maxvalsmoothed=0; + } + } + if (lostatcnt==len/2&&len>32&&maxvalgrablen>GRABSAMPLES-len) { + dprintk("SWAP problem detected! Fixing.\n"); + swap=!swap; + } down(&bt_sco->capture_sem); if (bt_sco->capture) { snd_card_bt_sco_pcm_receive ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bluez-devel] AGC and anti-noise patch for btsco kernel module 2005-08-22 18:53 ` [Bluez-devel] AGC and anti-noise patch for btsco kernel module Andreas Beck @ 2005-08-22 22:10 ` Brad Midgley 2005-08-23 15:04 ` Andreas Beck 0 siblings, 1 reply; 12+ messages in thread From: Brad Midgley @ 2005-08-22 22:10 UTC (permalink / raw) To: bluez-devel Andreas, The adaptive strategy you chose seems like it will work well. That was very quick coding and good intuition on the noise problem! I'll try the patch. Converting our kernel module to an alsa userspace driver is on the roadmap and I believe your approach could be used there as well. Marcel will probably ask why we don't fix the problem in the bluez layers if that's where it is, so every SCO app benefits. Can you surround the adaptive stuff and swapping stuff with two different macros so we can select them independently? Like USE_ADAPTIVE and USE_AUTOSWAP or something? Brad ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ 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] AGC and anti-noise patch for btsco kernel module 2005-08-22 22:10 ` Brad Midgley @ 2005-08-23 15:04 ` Andreas Beck 2005-08-23 16:05 ` Andreas Beck 0 siblings, 1 reply; 12+ messages in thread From: Andreas Beck @ 2005-08-23 15:04 UTC (permalink / raw) To: bluez-devel [-- Attachment #1: Type: text/plain, Size: 2279 bytes --] Brad Midgley <bmidgley@xmission.com> wrote: > Converting our kernel module to an alsa userspace driver is on the > roadmap and I believe your approach could be used there as well. Yeah. I like such copying-around much better in Userspace. Much less you can do wrong and _really_ mess things up. > Marcel will probably ask why we don't fix the problem in the bluez > layers if that's where it is, so every SCO app benefits. He's right. Depending on how the problem is created, my fix is actually flawed anyway, though it will mask the problem quite well. I handle it, as if it were an endianness problem. However it is probably a loosing data problem. As I just swap endianness, I group the data wrongly. This is probably only noticeable on high-pitched tones. Example: orig data: 1L 1H 2L 2H 3L 3H lost 1L: 1H 2L 2H 3L 3H with swap: 2L 1H 3L 2H ... Thus we will get 1H2L as a value. I group together bytes that don't belong together. We really should fix that in the SCO layer if possible. But I can as well think about a better fix. The downside of a better fix would be, that I need to keep around a byte for the next round of copying, as the last byte in a packet and the first in the next form a pair. How does the SCO socket react to short reads? I suppose it would give 1 byte and the 47 on the next, if I tried, right? It will usually give out the data packets just as they arrive - right? In that case I really only see one other fix: keeping around the byte from the last round. > Can you surround the adaptive stuff and swapping stuff with two > different macros so we can select them independently? Like USE_ADAPTIVE > and USE_AUTOSWAP or something? I have tried that. Attached. It makes the patch rather unwieldy, though, as I use the same mechanism to efficiently check the swap stuff and do the AGC. The patch should work for the none-defined and for the both-defined case. If it does for mixed cases, I just hope. I could probably make it more readable at the expense of speed by splitting the analysis loop in two. I'll think about a better swapping fix. Maybe I can make the stuff nicer to understand as well. Interim patch attached. CU, Andy -- = Andreas Beck | Email : <becka-sig@bedatec.de> = [-- Attachment #2: btsco.diff --] [-- Type: text/plain, Size: 6145 bytes --] Index: btsco.c =================================================================== RCS file: /cvsroot/bluetooth-alsa/btsco/kernel/btsco.c,v retrieving revision 1.6 diff -c -r1.6 btsco.c *** btsco.c 19 Mar 2005 14:28:59 -0000 1.6 --- btsco.c 23 Aug 2005 15:01:19 -0000 *************** *** 21,26 **** --- 21,46 ---- * */ + + /* note: defining these two independently is not tested, + * thus not recommended + */ + + /* enable dynamic compression */ + #define DYNAMIC_COMPRESSION + /* enable automatic endianness fixup */ + #define AUTO_FIXUP_ENDIANNESS + + + #ifdef DYNAMIC_COMPRESSION + /* Autoadjust mic at most this often in 1/8000s */ + #define GRABSAMPLES 400 + /* Maximum push for the mike 16= 1:1 - default 20:1 = 320 */ + #define COMPRESSION_MAX_16 320 + /* Minimum push for the mike 1= 1:16 */ + #define COMPRESSION_MIN_16 1 + #endif + #define chip_t snd_card_bt_sco_t #include <sound/driver.h> *************** *** 93,100 **** snd_card_t *card; spinlock_t mixer_lock; int mixer_volume[MIXER_ADDR_LAST + 1]; ! snd_kcontrol_t *mixer_controls[MIXER_ADDR_LAST + 2]; /* also loopback */ volatile int loopback; atomic_t playback_count, capture_count; volatile int count_changed; spinlock_t count_changed_lock; --- 113,127 ---- snd_card_t *card; spinlock_t mixer_lock; int mixer_volume[MIXER_ADDR_LAST + 1]; ! #ifdef DYNAMIC_COMPRESSION ! snd_kcontrol_t *mixer_controls[MIXER_ADDR_LAST + 2 + 1]; /* also loopback and agc */ ! #else ! snd_kcontrol_t *mixer_controls[MIXER_ADDR_LAST + 2 ]; /* also loopback */ ! #endif volatile int loopback; + #ifdef DYNAMIC_COMPRESSION + volatile int agc; + #endif atomic_t playback_count, capture_count; volatile int count_changed; spinlock_t count_changed_lock; *************** *** 569,574 **** --- 596,632 ---- return changed; } + #ifdef DYNAMIC_COMPRESSION + static int snd_bt_sco_agc_get(snd_kcontrol_t * kcontrol, + snd_ctl_elem_value_t * ucontrol) + { + snd_card_bt_sco_t *bt_sco = snd_kcontrol_chip(kcontrol); + unsigned long flags; + + spin_lock_irqsave(&bt_sco->mixer_lock, flags); + ucontrol->value.integer.value[0] = bt_sco->agc; + spin_unlock_irqrestore(&bt_sco->mixer_lock, flags); + return 0; + } + + static int snd_bt_sco_agc_put(snd_kcontrol_t * kcontrol, + snd_ctl_elem_value_t * ucontrol) + { + snd_card_bt_sco_t *bt_sco = snd_kcontrol_chip(kcontrol); + unsigned long flags; + int changed; + int agc; + + agc = !!ucontrol->value.integer.value[0]; + + spin_lock_irqsave(&bt_sco->mixer_lock, flags); + changed = bt_sco->agc != agc; + bt_sco->agc = agc; + spin_unlock_irqrestore(&bt_sco->mixer_lock, flags); + return changed; + } + #endif + #define BT_SCO_CONTROLS (sizeof(snd_bt_sco_controls)/sizeof(snd_kcontrol_new_t)) static snd_kcontrol_new_t snd_bt_sco_controls[] = { *************** *** 581,586 **** --- 639,654 ---- .get = snd_bt_sco_loopback_get, .put = snd_bt_sco_loopback_put, } + #ifdef DYNAMIC_COMPRESSION + , + {.iface = SNDRV_CTL_ELEM_IFACE_MIXER, + .name = "AGC Switch", + .index = 0, + .info = snd_bt_sco_boolean_info, + .get = snd_bt_sco_agc_get, + .put = snd_bt_sco_agc_put, + } + #endif }; int __init snd_card_bt_sco_new_mixer(snd_card_bt_sco_t * bt_sco) *************** *** 790,795 **** --- 858,874 ---- struct msghdr msg; struct iovec iov; sigset_t unblocked; + #if defined(DYNAMIC_COMPRESSION) || defined(AUTO_FIXUP_ENDIANNESS) + int i; + #endif + #ifdef DYNAMIC_COMPRESSION + static int factor=16; + static int maxvalsmoothed=0; + static int maxvalgrablen=GRABSAMPLES; /* adjust volume at most 4 times/second */ + #endif + #ifdef AUTO_FIXUP_ENDIANNESS + static int swap=0; + #endif lock_kernel(); *************** *** 839,844 **** --- 918,1000 ---- len = sock_recvmsg(sock, &msg, BUF_SIZE, 0); if (len > 0) { + #if defined (AUTO_FIXUP_ENDIANNESS) || defined (DYNAMIC_COMPRESSION) + int lostatcnt; + lostatcnt=0; + + if (len&1) dprintk("odd len %d\n",len); + for(i=0;i<len-1;i+=2) { + short int j; + int k; + + #ifdef AUTO_FIXUP_ENDIANNESS + if (swap) j=(buf[i]<<8)|buf[i+1]; + else j=(buf[i+1]<<8)|buf[i]; + #else + j=(buf[i+1]<<8)|buf[i]; + #endif + + #ifdef AUTO_FIXUP_ENDIANNESS + /* occasionally the Headset will loose a byte + * on startup. Thus swapping lo/hi. + * counting, if _all_ lo bytes (which are + * actually high bytes) are 0 or -1 + * will detect this with a very high probability + */ + if ((j&0xff)==0||(j&0xff)==0xff) { + lostatcnt++; + } + #endif + #ifdef DYNAMIC_COMPRESSION + /* scale the mic input - we do some kind + * of dynamics compression + */ + k=((int)j*factor)/16; + /* clip overshoot. Better than just letting + * it wrap around. Immediately adjust factor. + */ + if (k>0x7fff) { + k=0x7fff; + if (bt_sco->agc&&factor>COMPRESSION_MIN_16) factor--; + } else if (k<-0x8000) { + k=0x8000; + if (bt_sco->agc&&factor>COMPRESSION_MIN_16) factor--; + } + #else + k=j; + #endif + buf[i+1]=(k>>8)&0xff; + buf[i ]=k&0xff; + #ifdef DYNAMIC_COMPRESSION + /* find the highest absolute value in a + * GRABSAMPLES long interval. + */ + if (k<0) k=-j; + if (k>maxvalsmoothed) maxvalsmoothed=k; + /* if the interval is over, recalculate + * the compression factor. Move it slowly. + */ + if (maxvalgrablen--<=0) { + maxvalgrablen=GRABSAMPLES; + /* If the noise goes up over 1000, we stop + * pushing the software gain + */ + if (maxvalsmoothed<1000&&factor<COMPRESSION_MAX_16) { + factor++; + // dprintk("Up to %d\n",factor); + } + if (!bt_sco->agc) factor=16; + maxvalsmoothed=0; + } + #endif + } + #ifdef AUTO_FIXUP_ENDIANNESS + if (lostatcnt==len/2&&len>32&&maxvalgrablen>GRABSAMPLES-len) { + dprintk("SWAP problem detected! Fixing.\n"); + swap=!swap; + } + #endif + #endif /* any of them */ down(&bt_sco->capture_sem); if (bt_sco->capture) { snd_card_bt_sco_pcm_receive ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bluez-devel] AGC and anti-noise patch for btsco kernel module 2005-08-23 15:04 ` Andreas Beck @ 2005-08-23 16:05 ` Andreas Beck 0 siblings, 0 replies; 12+ messages in thread From: Andreas Beck @ 2005-08-23 16:05 UTC (permalink / raw) To: bluez-devel [-- Attachment #1: Type: text/plain, Size: 1249 bytes --] Andreas Beck <becka-bzdvl@bedatec.de> wrote: > He's right. Depending on how the problem is created, my fix is actually > flawed anyway, though it will mask the problem quite well. > I'll think about a better swapping fix. Maybe I can make the stuff > nicer to understand as well. [x] Done. New patch attached. Smaller, more readable and more correct. There is one catch, though, that I hadn't noticed before: If you turn on loopback and AGC together, chances are, that the headset will go into a feedback loop, emitting an unpleasant beep. This is a generic problem of loopback, which is only emphasized by the AGC, as it will (by its design) tune up input gain until it gets a significant signal. Feedback loop beep will occur, if total gain of the loop is >1. Actually the behaviour of the beep shows, that the AGC is working fine, as the beep will not go to full scale due to the AGC tuning down gain until the total gain is about 1. However I don't see much use for loopback mode anyway, and both are controllable in the mixer, so I don't think it will be much of a problem. If you need loopback, keep your fingers off AGC, or tune the parameters so that even max gain (COMPRESSION_MAX_16) will not trigger a feedback loop. CU, Andy [-- Attachment #2: btsco.diff --] [-- Type: text/plain, Size: 5624 bytes --] Index: btsco.c =================================================================== RCS file: /cvsroot/bluetooth-alsa/btsco/kernel/btsco.c,v retrieving revision 1.6 diff -u -r1.6 btsco.c --- btsco.c 19 Mar 2005 14:28:59 -0000 1.6 +++ btsco.c 23 Aug 2005 15:53:07 -0000 @@ -21,6 +21,26 @@ * */ + +/* note: defining these two independently is not tested, + * thus not recommended + */ + +/* enable dynamic compression */ +#define DYNAMIC_COMPRESSION +/* enable automatic endianness fixup */ +#define AUTO_FIXUP_BYTESHIFT + + +#ifdef DYNAMIC_COMPRESSION +/* Autoadjust mic at most this often in 1/8000s */ +#define GRABSAMPLES 400 +/* Maximum push for the mike 16= 1:1 - default 20:1 = 320 */ +#define COMPRESSION_MAX_16 320 +/* Minimum push for the mike 1= 1:16 */ +#define COMPRESSION_MIN_16 1 +#endif + #define chip_t snd_card_bt_sco_t #include <sound/driver.h> @@ -93,8 +113,15 @@ snd_card_t *card; spinlock_t mixer_lock; int mixer_volume[MIXER_ADDR_LAST + 1]; - snd_kcontrol_t *mixer_controls[MIXER_ADDR_LAST + 2]; /* also loopback */ +#ifdef DYNAMIC_COMPRESSION + snd_kcontrol_t *mixer_controls[MIXER_ADDR_LAST + 2 + 1]; /* also loopback and agc */ +#else + snd_kcontrol_t *mixer_controls[MIXER_ADDR_LAST + 2 ]; /* also loopback */ +#endif volatile int loopback; +#ifdef DYNAMIC_COMPRESSION + volatile int agc; +#endif atomic_t playback_count, capture_count; volatile int count_changed; spinlock_t count_changed_lock; @@ -569,6 +596,37 @@ return changed; } +#ifdef DYNAMIC_COMPRESSION +static int snd_bt_sco_agc_get(snd_kcontrol_t * kcontrol, + snd_ctl_elem_value_t * ucontrol) +{ + snd_card_bt_sco_t *bt_sco = snd_kcontrol_chip(kcontrol); + unsigned long flags; + + spin_lock_irqsave(&bt_sco->mixer_lock, flags); + ucontrol->value.integer.value[0] = bt_sco->agc; + spin_unlock_irqrestore(&bt_sco->mixer_lock, flags); + return 0; +} + +static int snd_bt_sco_agc_put(snd_kcontrol_t * kcontrol, + snd_ctl_elem_value_t * ucontrol) +{ + snd_card_bt_sco_t *bt_sco = snd_kcontrol_chip(kcontrol); + unsigned long flags; + int changed; + int agc; + + agc = !!ucontrol->value.integer.value[0]; + + spin_lock_irqsave(&bt_sco->mixer_lock, flags); + changed = bt_sco->agc != agc; + bt_sco->agc = agc; + spin_unlock_irqrestore(&bt_sco->mixer_lock, flags); + return changed; +} +#endif + #define BT_SCO_CONTROLS (sizeof(snd_bt_sco_controls)/sizeof(snd_kcontrol_new_t)) static snd_kcontrol_new_t snd_bt_sco_controls[] = { @@ -581,6 +639,16 @@ .get = snd_bt_sco_loopback_get, .put = snd_bt_sco_loopback_put, } +#ifdef DYNAMIC_COMPRESSION + , + {.iface = SNDRV_CTL_ELEM_IFACE_MIXER, + .name = "AGC Switch", + .index = 0, + .info = snd_bt_sco_boolean_info, + .get = snd_bt_sco_agc_get, + .put = snd_bt_sco_agc_put, + } +#endif }; int __init snd_card_bt_sco_new_mixer(snd_card_bt_sco_t * bt_sco) @@ -790,6 +858,18 @@ struct msghdr msg; struct iovec iov; sigset_t unblocked; +#if defined(DYNAMIC_COMPRESSION) || defined(AUTO_FIXUP_BYTESHIFT) + int i; +#endif +#ifdef DYNAMIC_COMPRESSION + static int factor=16; + static int maxvalsmoothed=0; + static int maxvalgrablen=GRABSAMPLES; /* adjust volume at most 4 times/second */ +#endif +#ifdef AUTO_FIXUP_BYTESHIFT + static int shift=0; + static unsigned char lastbyte; +#endif lock_kernel(); @@ -839,6 +919,85 @@ len = sock_recvmsg(sock, &msg, BUF_SIZE, 0); if (len > 0) { +#if defined (AUTO_FIXUP_BYTESHIFT) || defined (DYNAMIC_COMPRESSION) + +#ifdef AUTO_FIXUP_BYTESHIFT + int lostatcnt=0; +#endif + if (len&1) dprintk("odd len %d\n",len); +#ifdef AUTO_FIXUP_BYTESHIFT + if (shift) { + unsigned char newlastbyte; + newlastbyte=buf[len-1]; + memmove(buf+1,buf,len-1); + buf[0]=lastbyte; + lastbyte=newlastbyte; + } +#endif + for(i=0;i<len-1;i+=2) { + short int j; + int k; + j=(buf[i+1]<<8)|buf[i]; + +#ifdef AUTO_FIXUP_BYTESHIFT + /* occasionally the Headset will loose a byte + * on startup. Thus kind of swapping lo/hi. + * counting, if _all_ lo bytes (which are + * actually high bytes) are 0 or -1 + * will detect this with a very high probability + */ + if ((j&0xff)==0||(j&0xff)==0xff) { + lostatcnt++; + } +#endif +#ifdef DYNAMIC_COMPRESSION + /* scale the mic input - we do some kind + * of dynamics compression + */ + k=((int)j*factor)/16; + + /* clip overshoot. Better than just letting + * it wrap around. Immediately adjust factor. + */ + if (k>0x7fff) { + k=0x7fff; + if (bt_sco->agc&&factor>COMPRESSION_MIN_16) factor--; + } else if (k<-0x8000) { + k=0x8000; + if (bt_sco->agc&&factor>COMPRESSION_MIN_16) factor--; + } + buf[i+1]=(k>>8)&0xff; + buf[i ]=k&0xff; + + /* find the highest absolute value in a + * GRABSAMPLES long interval. + */ + if (k<0) k=-j; + if (k>maxvalsmoothed) maxvalsmoothed=k; + /* if the interval is over, recalculate + * the compression factor. Move it slowly. + */ + if (maxvalgrablen--<=0) { + maxvalgrablen=GRABSAMPLES; + /* If the noise goes up over 1000, we stop + * pushing the software gain + */ + if (maxvalsmoothed<1000&&factor<COMPRESSION_MAX_16) { + factor++; + // dprintk("Up to %d\n",factor); + } + if (!bt_sco->agc) factor=16; + maxvalsmoothed=0; + } +#endif + } +#ifdef AUTO_FIXUP_BYTESHIFT + if (lostatcnt==len/2&&len>32) { + shift=!shift; + dprintk("Shift problem detected! Fixing to %d.\n",shift); + } +#endif +#endif /* any of them */ down(&bt_sco->capture_sem); if (bt_sco->capture) { snd_card_bt_sco_pcm_receive ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2005-08-23 16:05 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-08-19 19:38 [Bluez-devel] btsco - a few comments and a small .py script Andreas Beck 2005-08-19 20:44 ` John Gruenenfelder 2005-08-20 20:13 ` Brad Midgley 2005-08-21 12:12 ` Andreas Beck 2005-08-21 19:26 ` Andreas Beck 2005-08-22 4:29 ` Brad Midgley 2005-08-22 12:09 ` Andreas Beck 2005-08-22 18:38 ` Andreas Beck 2005-08-22 18:53 ` [Bluez-devel] AGC and anti-noise patch for btsco kernel module Andreas Beck 2005-08-22 22:10 ` Brad Midgley 2005-08-23 15:04 ` Andreas Beck 2005-08-23 16:05 ` Andreas Beck
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.