This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/AM4378: Bluetooth audio data not playing

Part Number: AM4378

Tool/software: Linux

I'm trying to run the LinuxHFRM_HF sample program on the AM437x EVM, but I cannot get the Bluetooth audio to play out the headphone out jack. I'm able to connect to an iPhone and make a call, and all of the commands work (like redial, end call, etc.), but I don't hear any audio playing out the headphone jack. I have the audio routed in my .dts file and it seems like everything is set up correctly because the program indicates on power up that the pipeline is set up correctly, and that Gstreamer starts.

Is there something else that I need to do in order to get the audio to play? I'm looking at the source code in LinuxHFRM_HF.c, and it looks like a message should be printed every 1s when audio data is being received, but those messages are not being displayed. It seems like the HFRM_Event_Callback() function is not being triggered by audio data. Please let me know your thoughts, thanks.

  • Humm.. I thought, you got the HFP demo working, as per this thread. Is this different?

    e2e.ti.com/.../768492

    Thanks
  • I thought it was working, and everything besides the audio data is working. I can start a call, end a call, enter DTMF, etc. but there is no audio data. The audio data is not triggering the HFRM_Event_Callback() function.
  • From what I've been able to find online, it seems like it could be an issue with pulseaudio? Apparently pulseaudio is needed for Bluetooth audio to work? Is that correct, and if so how can I run pulseaudio? Whenever I try to run it I get the error:

    W: [pulseaudio] main.c: This program is not intended to be run as root (unless --system is specified).
    E: [pulseaudio] main.c: Daemon startup failed.

    And when I try to run it with the --system flag, I get the following error:

    W: [pulseaudio] main.c: Running in system mode, but --disallow-exit not set.
    W: [pulseaudio] main.c: Running in system mode, but --disallow-module-loading not set.
    N: [pulseaudio] main.c: Running in system mode, forcibly disabling SHM mode.
    N: [pulseaudio] main.c: Running in system mode, forcibly disabling exit idle time.
    W: [pulseaudio] main.c: OK, so you are running PA in system mode. Please note that you most likely shouldn't be doing that.
    W: [pulseaudio] main.c: If you do it nonetheless then it's your own fault if things don't work as expected.
    W: [pulseaudio] main.c: Please read www.freedesktop.org/.../ for an explanation why system mode is usually a bad idea.
    W: [pulseaudio] sink.c: Default and alternate sample rates are the same.
    W: [pulseaudio] source.c: Default and alternate sample rates are the same.
    W: [pulseaudio] authkey.c: Failed to open cookie file '/etc//pulse/cookie': No such file or directory
    W: [pulseaudio] authkey.c: Failed to load authentication key '/etc//pulse/cookie': No such file or directory
    W: [pulseaudio] authkey.c: Failed to open cookie file '/var/run/pulse/.pulse-cookie': No such file or directory
    W: [pulseaudio] authkey.c: Failed to load authentication key '/var/run/pulse/.pulse-cookie': No such file or directory
    W: [pulseaudio] authkey.c: Failed to open cookie file '/etc//pulse/cookie': No such file or directory
    W: [pulseaudio] authkey.c: Failed to load authentication key '/etc//pulse/cookie': No such file or directory
    E: [pulseaudio] module.c: Failed to load module "module-native-protocol-unix" (argument: ""): initialization failed.
    E: [pulseaudio] main.c: Module load failed.
    E: [pulseaudio] main.c: Failed to initialize daemon.
  • Humm.. I do not think pulse audio is needed.. I believe, all that is needed is ALSA..

    As, i noted earlier we have not tried the ALSA routing patches in a while with recent kernels. I will try to make build and test it on AM43x EVM and get back to you soon..

    Thanks
  • Not yet.. I have some AM43x setup issues, trying to resolve them.. Will get back in a day or two..

    Thanks
  • We, are still working on this issue.. As, you noted with our patch builds on top of TISDK5.1 kernel, we hear no voice, even though from the WL18xx BT controller point of view every thing looks fine.. As, I said earlier we are not testing these assisted modes with each TISDK release and so not sure when it got broken.. I tried both the AG and HF modes and both failed with no voice.. We, took some BT snoop logs as well to check the RFCOMM, SDP interactions before the audio connection and they all seem fine..
    We, will now probe the PCM connections between the AM437x and the COM8, to check further.. We, will keep you posted as we identify the issue and the resolution..

    Thanks
  • Okay, yes just keep me posted. Thank you for the update.
  • Just to give you an update - We, have now verified the voice from peer (phone) to the AM437x Bt PCM and routed to AM437x AIC speakers working.. We, will now check in the other direction and provide you the patches..

    Thanks
  • Hey Hari,

    Just checking in, do you have an idea of when the patches will be available?
  • Sorry for the delay... I shared the files, please give it a try... We, will clean the patches with more comments etc and upload to our server soon..

    Thanks
  • Please, let us know if the patches worked Ok..

    Thanks
  • Yes, I will let you know. It might be a little bit before I get to try them out because we just got our custom boards, so I am currently working on getting that up and running. But once I get a chance (hopefully I will have time this week) I will try the patches out and let you know if they work.
  • Ok.. I thought you were trying on the AM437x EVM. If, you are using some other board, you would need to make sure correct McASP, pin muxes are configured in the DTB.. Anyways, i will close the thread for now. Please, re-open or rise a new one if you have issues..

    Thanks
  • Yes, I was trying it on the EVM but we are also in the process of bringing up a board. I will try the patches on the EVM first and then I'll try doing it on our custom board and I'll let you know how it goes.