[pulseaudio-discuss] [BUG] Using bluez 5.5 & pulseaudio a bluetooth headset cannot be used as a recording device.
Alexander Winnig
vernehmlassung at googlemail.com
Wed Jun 5 02:15:07 PDT 2013
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)
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.
> 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 &//
//[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)>//
/
Result
ausgabehci.txt: 0 Bytes
neu.wav: 0 Bytes
Best
Alexander
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20130605/b7d49e35/attachment-0001.html>
More information about the pulseaudio-discuss
mailing list