<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">Thanks. </div> <blockquote cite="mid:CANT-zCUaEcTerx+++=zOQofHXcTyRE7MqO2K3BT_XPvSppH+3w@mail.gmail.com" type="cite"> <pre wrap="">Hi Alex, On Tue, Jun 4, 2013 at 9:45 PM, Alexander Winnig <a class="moz-txt-link-rfc2396E" href="mailto:vernehmlassung@googlemail.com"><vernehmlassung@googlemail.com></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">Thanks Mikel. Am 04.06.2013 14:02, schrieb Mikel Astiz: parecord -r --device=bluez_source.00_1A_7D_11_C0_66 mm.wav in my case. Creates a crackling sound in the earpiece and a mm.wav of zero bytes, no matter how long I record. I tried to reproduce your issue without success, with two different headsets. It could be an issue with your specific headset (any chance you can test a different one?) or more likely, according to your previous messages, your system is broken with multiple versions of the same component or an incorrect configuration (PulseAudio, BlueZ). I re-copied a new wheezy-image on my sd-card. Now pactl list sources short shows the bluez-device. But still, an empty file is the output. So a broken system/incorrect configuration is unlikely now. A possible checklist you could follow is: 1. Make sure BlueZ's audio.conf is properly set. You might need to add a line with "Disable=Socket". Done. 2. Make sure the headset is connected (PA card exists) and profile is set to "hsp". Done. 3. During recording, make sure the profile's state is set to "available: yes". You can see this with pacmd list-cards. This is what I get: pi@raspberrypi ~ $ parecord -r -d "bluez_source.00_1A_7D_11_C0_66" mm.wav & [1] 2828 pi@raspberrypi ~ $ pacmd list-cards ..... index: 4 name: <bluez_card.00_1A_7D_11_C0_66> driver: <module-bluetooth-device.c> owner module: 24 properties: device.description = "Iqua Slim" device.string = "00:1A:7D:11:C0:66" device.api = "bluez" device.class = "sound" device.bus = "bluetooth" device.form_factor = "headset" bluez.path = "/org/bluez/1981/hci0/dev_00_1A_7D_11_C0_66" bluez.class = "0x240404" bluez.name = "Iqua Slim" device.icon_name = "audio-headset-bluetooth" device.intended_roles = "phone" profiles: a2dp: High Fidelity Playback (A2DP) (priority 10) hsp: Telephony Duplex (HSP/HFP) (priority 20) </pre> </blockquote> <pre wrap=""> Which version of PulseAudio/pacmd are you using? 4.0 would have shown the profile availability here.</pre> </blockquote> pulseaudio 2.0 pacmd 2.0(Compiled with libpulse 2.0.0, Linked with libpulse 2.0.0) If I have to get the newest pulseaudio for my purpose, please tell me how to exactly configure, make and make install it for it to work this time. I won't install it if it's just nice-to-have. <blockquote cite="mid:CANT-zCUaEcTerx+++=zOQofHXcTyRE7MqO2K3BT_XPvSppH+3w@mail.gmail.com" type="cite"> <pre wrap="">In any case, the state of the source below already confims the SCO state. </pre> <blockquote type="cite"> <pre wrap=""> off: Off (priority 0) active profile: <hsp> sinks: bluez_sink.00_1A_7D_11_C0_66/#3: Iqua Slim sources: bluez_sink.00_1A_7D_11_C0_66.monitor/#5: Monitor of Iqua Slim bluez_source.00_1A_7D_11_C0_66/#6: Iqua Slim ports: 4. During recording, make sure the source is "state: RUNNING" (pacmd list-sources). This confirms (3) meaning that SCO audio is streaming fine. I used pactl list sources short. It showed 1 bluez_sink.00_1A_7D_11_C0_66.monitor module-bluetooth-device.c s16le 1ch 8000Hz SUSPENDED 2 bluez_source.00_1A_7D_11_C0_66 module-bluetooth-device.c s16le 1ch 8000Hz RUNNING </pre> </blockquote> <pre wrap=""> This looks good. Can you check list-sinks? I believe the headset sink will be suspended, but let's confirm it.</pre> </blockquote> .... index: 1 name: <bluez_sink.00_1A_7D_11_C0_66> driver: <module-bluetooth-device.c> flags: HARDWARE HW_VOLUME_CTRL LATENCY state: IDLE suspend cause: priority: 9030 volume: 0: 53% balance 0.00 base volume: 100% volume steps: 16 muted: no current latency: 137.00 ms max request: 0 KiB max rewind: 0 KiB monitor source: 1 sample spec: s16le 1ch 8000Hz channel map: mono Mono used by: 0 linked by: 0 fixed latency: 128.00 ms card: 1 <bluez_card.00_1A_7D_11_C0_66> module: 6 properties: bluetooth.protocol = "sco" device.intended_roles = "phone" device.description = "Iqua Slim" device.string = "00:1A:7D:11:C0:66" device.api = "bluez" device.class = "sound" device.bus = "bluetooth" device.form_factor = "headset" bluez.path = "/org/bluez/1980/hci0/dev_00_1A_7D_11_C0_66" bluez.class = "0x240404" bluez.name = "Iqua Slim" device.icon_name = "audio-headset-bluetooth" <blockquote cite="mid:CANT-zCUaEcTerx+++=zOQofHXcTyRE7MqO2K3BT_XPvSppH+3w@mail.gmail.com" type="cite"> <blockquote type="cite"> <pre wrap="">If all this work fine but the issue persists, I'd have to see the output of hcidump during recording. This is all hcidump gives: HCI sniffer - Bluetooth packet analyzer ver 2.4 device: hci0 snap_len: 1028 filter: 0xffffffff and a waiting green square not returning to the command line. When I disconnected the headset I got </pre> <blockquote type="cite"> <pre wrap="">HCI Event: Inquiry Result (0x02) plen 20 </pre> </blockquote> <pre wrap=""> bdaddr 00:A0:02:00:0C:00 mode 19 clkoffset 0x1300 class 0x02000c bdaddr 00:02:00:0C:01:05 mode 0 clkoffset 0x0000 class 0x000000 bdaddr 00:00:00:00:00:00 mode 0 clkoffset 0x0000 class 0x000000 bdaddr 00:00:00:00:00:00 mode 0 clkoffset 0x0000 class 0x000000 bdaddr 00:00:00:00:00:00 mode 0 clkoffset 0x0000 class 0x000000 bdaddr 00:00:00:00:00:00 mode 0 clkoffset 0x0000 class 0x000000 Stream-Fehler: Entität terminiert </pre> <blockquote type="cite"> <pre wrap="">HCI Event: Disconn Complete (0x05) plen 4 </pre> </blockquote> <pre wrap=""> status 0x00 handle 12 reason 0x13 Reason: Remote User Terminated Connection </pre> </blockquote> <pre wrap=""> It seems the SCO link (the actual audio stream) is up but there's no audio flowing.</pre> </blockquote> That's what I am saying. I presume the headset needs a RING AT command, then listen for the accept button to be pressed on the headset then initiate the audio connection. But as i said, play() doesn't work with python like my stackoverflow example shows. <blockquote cite="mid:CANT-zCUaEcTerx+++=zOQofHXcTyRE7MqO2K3BT_XPvSppH+3w@mail.gmail.com" type="cite"> <pre wrap=""> Which hardware are you testing this on? You mentioned you're using a raspberry pi, which I believe doesn't have a built-in bluetooth chip. Are you using some conventional USB dongle?</pre> </blockquote> An expensive belkin bluetooth 4.0+ adapter. <blockquote cite="mid:CANT-zCUaEcTerx+++=zOQofHXcTyRE7MqO2K3BT_XPvSppH+3w@mail.gmail.com" type="cite"> <pre wrap=""> I ask this because the hardware could be set up for SCO over PCM (as opposed to SCO over HCI) which would lead to the described behavior. Otherwise, assuming it's SCO over HCI, the hcidump above would be pretty bad. I haven't seen this before but it's definitely possible that the headset doesn't send any audio unless it receives some, which is not happening in this case. You should be able to confirm this by sending some audio to the headset with paplay during the recording, and checking if parecord works during this time. hcidump would be interesting here too.</pre> </blockquote> This is what I did <blockquote>hcidump > ausgabehci.txt & [1] 2447 parecord -r -d "bluez_source.00_1A_7D_11_C0_66" neu.wav & [2] 2448 paplay -p -d "bluez_sink.00_1A_7D_11_C0_66" under.wav <Wait some seconds(I hear no sound in my headset)> </blockquote> Result ausgabehci.txt: 0 Bytes neu.wav: 0 Bytes Best Alexander </body> </html>