[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]

 



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>


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

  Powered by Linux