[pulseaudio-discuss] [BUG] Using bluez 5.5 & pulseaudio a bluetooth headset cannot be used as a recording device.
Mikel Astiz
mikel.astiz.oss at gmail.com
Thu Jun 6 00:58:07 PDT 2013
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
More information about the pulseaudio-discuss
mailing list