Hi Alex, On Wed, Jun 5, 2013 at 11:15 AM, Alexander Winnig <vernehmlassung at googlemail.com> wrote: > Thanks. > > Hi Alex, > > On Tue, Jun 4, 2013 at 9:45 PM, Alexander Winnig > <vernehmlassung at googlemail.com> wrote: > > 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 at raspberrypi ~ $ parecord -r -d "bluez_source.00_1A_7D_11_C0_66" mm.wav & > [1] 2828 > pi at 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) > > Which version of PulseAudio/pacmd are you using? 4.0 would have shown > the profile availability here. > > pulseaudio 2.0 > pacmd 2.0(Compiled with libpulse 2.0.0, Linked with libpulse 2.0.0) I can't help you much with such a version. I however did follow your steps with 2.0 and couldn't reproduce the issue either. So it points to be an issue with your specific headset. I would suggest you try with a different one to confirm. > > 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. It's your choice to decide if you want to test a more recent version or not, nothing's guaranteed. You will find the instructions in the documentation but I can at least point out that you'll need to install the sbc library, which is a new dependency. > > > In any case, the state of the source below already confims the SCO state. > > 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 > > This looks good. > > Can you check list-sinks? I believe the headset sink will be > suspended, but let's confirm it. > > .... > 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" > > > 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 > > HCI Event: Inquiry Result (0x02) plen 20 > > 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 > > HCI Event: Disconn Complete (0x05) plen 4 > > status 0x00 handle 12 reason 0x13 > Reason: Remote User Terminated Connection > > It seems the SCO link (the actual audio stream) is up but there's no > audio flowing. > > 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. > > > 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? > > An expensive belkin bluetooth 4.0+ adapter. > > > 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. > > This is what I did > > hcidump > ausgabehci.txt & Without sudo? > [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)> This basically discards my best hypothesis. > > Result > > ausgabehci.txt: 0 Bytes There's something wrong with the test because this is impossible or very unlikely. You actually did send us traces before with some HCI traces. Cheers, Mikel > neu.wav: 0 Bytes > > Best > > Alexander
