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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux