• Hi everyone.

    On an armstonea9r2board, I'm trying to pair a bluetooth headphones.

    On buildroot, I've enabled the following packages:

    Code
    1. target packages --> Networking applications --> bluez-utils 5.x
    2. target packages --> Networking applications --> bluez-utils 5.x --> build CLI client
    3. target packages --> Audio and video applications -> bluez-alsa
    4. target packages --> Audio and video applications -> bluez-alsa --> hcitop
    5. target packages --> Audio and video applications -> bluez-alsa --> rfcom


    compilation and deployment on the board is successful.

    I can successfully raise the hci0interface (hciconfig hci0 up) and scan for devices (hcitool scan); I can also read both the name of the device and the device info through the commands: hcitool name <device address> and hcitool info <device address>, but seems I cannot pair the headphones (hcitool cc <device addr>), as -even if the command doesn't return any error, any next command requiring an active connection raises an error (such as hcitool rssi).


    Moreover, when I try to test the headphone through bluealsa-aplay the following error is raised:

    bluealsa-aplay: BlueALSA connection failed: No such file or directory

    and this confirm the missing connection.


    When launching bluealsa (which is the bluetooth daemon, right?), the following error is raised:

    bluealsa: Couldn't get managed objects: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.bluez was not provided by any .service files


    Looking into the /etc/dbus-1/system.d path, I can see a bluetooth.conf file allowing for the security policies of the bluetooth daemon, but Googling the above message I've found nothing applicable for an embedded system (many user reported the needs to add users into specific groups, and so on...)


    Trying to tackle the problem with a completely different approach, I saw in many posts the usage of the bluetoothctl command to pair devices, which in my case opens successfully a prompt interface, but doesn't allow to enter any command.

    On forums this behavior is reported to be connected with the bluetooth daemon not started (specifically bluetoothd), that effectively is missing from the active processes and can't also be found on the executable deployed on the board (which is bluealsa according to the first approach).

    I've searched a way to get bluetoothd deployed on the board through buildroot, but I can't find any way.


    I'm a newbie on this topic: I admit I don't have a full understanding on what is happening and surely I'm missing some steps...


    Do you have any hints on how to pair a headphone and stream some audio through bluez-alsa (or other framework?)



    Thanks and BR,

    Michele Bucceri

  • Thanks!

    Indeed, yes, finally I got bluetoothd (I think I simply made a wrong lookup: it was there since yesterday!).


    Some progress:

    • satrted bluetoothd
    • started bluealsa (now starts without any error: that's because bluetoothdis providing the requested service)
    • entered the bluetoothctl interactive shell. Now is possible to power-on the bluetooth, starts the agent, make the discovery, pair and connect with the device.

    The last step missing is that in the alsa backend the bluetooth device is still missing (aplay -L won't show any other device than the imxsgtl5000 and imxhdmisoc), so is still impossible to stream to the headphones...


    Michele

  • Yes and it didn't work:

    Code
    1. # aplay -v -D bluealsa:DEV=41:42:81:B1:BD:F3 horse.wav
    2. ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM bluealsa:DEV=41:42:81:B1:BD:F3
    3. aplay: main:828: audio open error: No such file or directory

    even specifying other parameters such as HCI=hci0, PROFILE=a2dp


    And this is compatible with the following:

    Code
    1. # aplay -L
    2. null
    3. Discard all samples (playback) or generate zero samples (capture)
    4. sysdefault:CARD=imxsgtl5000
    5. imx-sgtl5000,
    6. Default Audio Device
    7. sysdefault:CARD=imxhdmisoc
    8. imx-hdmi-soc,
    9. Default Audio Device

    the command bluealsa-aplay -L won't work as it seems there is no option -L

  • Great,

    now it works!!!


    From aplay -L the device is not listed, but specifying the BT MAC address of the device aplay stream on the headphones.

    Moreover, adding the .asoundrc configuration file in the home directory, the device -if connected- became the default device.


    Last thing to do is to have our application working: it gets stuck immediately after connecting to the device; we use the portaudio library to interface with the sound bus.


    The following error is thrown:

    ALSA lib bluealsa-pcm.c:714:(_snd_pcm_bluealsa_open) Couldn't get BlueALSA transport: No such device or address


    Just digging some more...


    Michele

  • Hi,

    I tried with different sample rates and setting also the environment variable, as suggested by the above post, but the applications still hangs when opening the audio stream within the PortAudio library.


    Also tested with the test programs provided with PortAudio and the behavior is the same.

    The only way to make it working with PortAudio is to change the streaming mode, switching from the unblocking mode to the blocking mode; it seems there is some problem in the thread management within the PortAudio library, but I admit I have not enough knowledge to fully understand what's going on.


    Now I'll try to update our app and feed the audio stream using the blocking methods...


    Michele

  • Just a side remark: If this is just a private project, everything is fine. But if you plan to sell this device to end customers, and you are using Bluetooth technology, then you are responsible for ensuring that the device is properly registered, certified and approved. This usually requires registering with the Bluetooth organization (SIG) and getting a QDID for the final device. To get a QDID, a test lab has to verify the compliance of hardware and software with the Bluetooth specification. This is typically not trivial and may even be quite expensive.


    This is completely different to using a USB Bluetooth device for example that is plugged into a USB port. Such a device is a separate standalone product that already has a valid certification of its own.


    The on-board WLAN/Bluetooth chip on the armStoneA9r2 is only part of a device. As the final certification must be done with the end product, it is always in your responsibility to do this certification. But of course we can support you when doing this.


    Your F&S Support Team

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.