[pulseaudio-discuss] [BUG] Using bluez 5.5 & pulseaudio a bluetooth headset cannot be used as a recording device.

[Mikel Astiz]

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.

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.

>
>
> 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.

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?

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.

Cheers,
Mikel