Android CAF / QUALCOMM audio routing bug

Products Support DragonBoard410c
#1

@kiran @ljking or anybody else who works for Qualcomm, or anybody who just knows anything about the audio routing on these qualcomm boards…

The problem: there is no AUDIO in Bluetooth HFP-Client mode.

HFP-Client mode works, in general. It is possible to control calls using the protocol via bttestapp included in the builds for DB410c. When in a call, the cellphone (Nexus 6 with factory firmware) routes audio to the DB410c as expected. Everything through the entire process works exactly as expected, except that there is no sound.

Note: audio_policy.conf has been modified so that it selects SPEAKER by default, instead of handset. The logcat during an HFP-Client session indicates that the output device is voice-speaker, and input device is voice-speaker-mic, both correct.

Errors during the HFP-CLient session indicated that it was missing paths named “hfp-sco” and “hfp-sco-wb”.

So I found the following from mixer_paths_mtp.xml:


    <path name="hfp-sco">
        <ctl name="PRI_MI2S_RX Port Mixer INTERNAL_BT_SCO_TX" value="1" />
        <ctl name="INTERNAL_BT_SCO_RX Audio Mixer MultiMedia6" value="1" />
        <ctl name="MultiMedia6 Mixer TERT_MI2S_TX" value="1" />
        <ctl name="HFP_INT_UL_HL Switch" value="1" />
    </path>

    <path name="hfp-sco-wb">
        <ctl name="Internal BTSCO SampleRate" value="16000" />
        <path name="hfp-sco" />
    </path>

Now this… obviously does not work. To start with, PRI_MI2S_RX and TERT_MI2S_TX go nowhere on DB410c. If I’m not mistaken, “PRI_MI2S_RX” is the thing that RECEIVES DATA (hence RX) to send out on the PRI_MI2S, which is the PCM-OUT pin on the low speed expansion header. Also, it doesn’t seem like the TERT_MI2S_TX is actually connected to anything. That would be the thing that TRANSMITS DATA that was received from the TERT_MI2S, which appears to be N/C.

So the most immediately obvious change to make, is to swap out PRI_MI2S_RX for QUAT_MI2S_RX, but that isn’t going to work, because there is no control named “QUAT_MI2S_RX Port Mixer INTERNAL_BT_SCO_TX” defined in the kernel.

So I tried to define the control by adding;

SOC_SINGLE_EXT(“INTERNAL_BT_SCO_TX”, MSM_BACKEND_DAI_QUATERNARY_MI2S_RX,
MSM_BACKEND_DAI_INT_BT_SCO_TX, 1, 0, msm_routing_get_port_mixer,
msm_routing_put_port_mixer),

to quat_mi2s_rx_port_mixer_controls[]

and

{“QUAT_MI2S_RX Port Mixer”, “INTERNAL_BT_SCO_TX”, “INT_BT_SCO_TX”},

to intercon[]

Both in kernel/sound/soc/msm/qdsp6v2/msm-pcm-routing-v2.h

Still no sound out on the HDMI though…

Mind you, this approach really doesn’t “feel” right, since it won’t take account for the input and output devices that were selected (i.e. voice-speaker and voice-speaker-mic).

But there are other things about this that are odd; for instance, what is the relationship between INTERNAL_BT_SCO_TX, INTERNAL_BT_SCO_RX, INT_HFP_BT Hostless, and MultiMedia6 (aka MSM8916 HFP TX?) ??

So I guess the question is this; how do I get the audio stream coming in from the bluetooth to come out with the HDMI? And how do I turn the audio coming in one of the microphones into a stream out the bluetooth?

Note: A2DP-sink is working perfectly (including AVRCP). Conceptually, HFP-client is not very different, except that it adds an outbound audio stream as well.

#2

Hi ,

Can you please share the logcat , snoop and OTA logs .Please generate all the logs simultaneously and share and also let us know that how you confirm that Audio is routed from mobile(Nexus 6) to DB410c board

Thanks,
Sivaram

#3

Thank you Sivaram,

I will do so as soon as I get home from work this afternoon, I should have it for you around 6 PM (North America Eastern).

If you could clarify a couple of things though…

  1. what is an OTA log? Search results are plugged up with references to “Over The Air updates”.
  2. what would be the best configuration for the device (db410c) during the log capturing session? I’m thinking audio policy set such that it routes voice calls to the speaker (quat mi2s / hdmi converter chip), mixer file from sbc, but with the two paths copied verbatim from the mtp mixer file, and original kernel. Is this reasonable? Or should I do it with the adjustments I described previously? Or both?

As far as knowing that the Nexus 6 is producing the sound as expected, partly this is on faith that the Nexus 6 is actually working correctly. It does do calls on bluetooth with other devices, such as a kenwood dnx6960 and a parrot asteroid smart. In addition, it does allow switching audio routes as normal, between its own earpiece, speaker, and bluetooth. Further, hfptestapp (https://www.codeaurora.org/cgit/quic/la/platform/vendor/qcom-opensource/bluetooth/) on the db410c has a switch/indicator referring to where the audio is actually being routed. I can provide the same logs from the Nexus 6 as well, if you think that would be useful.

The full testing setup is like this;
Call is originating on a Nexus 9 tablet via Google Hangouts. From that, I place a voice call to the Nexus 6 using regular old phone number on HSPA network, and connect via HFP to the db410c. The audio is being received from the Nexus 9, since when the Nexus 6 is set to speaker or handset mode, sound from the Nexus 9 microphone can be heard from the Nexus 6, feedback and all.

Is there an email address I can send these logs to? Mainly because they will contain some sensitive information, like one of my phone numbers…

#4

Hi,

Thank you for the information.

  1. what is an OTA log? Search results are plugged up with references to “Over The Air updates"

yes, OTA means “over the Air” . you can take OTA logs through the Bluetooth sniffer, which is an external hardware.

Please let us know if you have QXDM. so that we will share DMC file, if possible.QXDM logs might be helpful to debug the issue more.

  1. what would be the best configuration for the device (db410c) during the log capturing session?
    what do you mean by the best configuration?
    is the configuration regarding OTA logs or any other logs ?

Please provide DB410c logs as well as Nexus6 logs.you can forward logs to c_snarra@qti.qualcomm.com

Thanks,
Sivaram.

#5

Ok, I don’t have a bluetooth sniffer or QXDM, so I won’t be able to get those logs.
EDIT: I looked for QXDM, but can only see sketchy looking pirated software, and only windows version which I would not even be able to run.

I tried to describe what I meant by the configuration. I guess it didn’t really make sense to you.

I will try to describe what I mean differently;

  1. First possible configuration, is to test the device with the software set up exactly how it ships; That means that it will try to set analog audio playback device to non-existent handset, and analog audio capture device to handset-mic. This setup will generate an error in the logcat complaining about missing audio paths “hfp-sco” and “hfp-sco-wb”, as well as kernel error involving “MSM8916 HFP TX”.

  2. Second option is to modify audio policy file to attempt to direct audio playback to “speaker”, which routes to the adv7533 hdmi converter chip and provides analog output on the HDMI monitor, and input from speaker-mic. With just this change, it will still make kernel and logcat errors related to the missing audio paths.

  3. Third option is to modify the mixer file to add in the “hfp-sco” and “hfp-sco-wb” sections exactly the same as in the mtp mixer file. Without this change, it will cause both kernel error and logcat error.

  4. Fourth option is to modify the kernel to add a control named “QUAT_MI2S_RX Port Mixer INTERNAL_BT_SCO_TX”, and modify the path “hfp-sco” to use that instead of PRI_MI2S_RX.

#6

Looks to me like the hci sniffing mode in Android should pick up everything that a hardware snooping device would, except for sources of interference from competing BT devices and wifi.

Its probably worth noting that bt-coex does not appear to be working on this device, since wifi dies when bt is streaming. Not important to me though, since I don’t actually need wifi.

#7

Hello,

please ignore QXDM, we will validate this and get back on the forum soon.

Thanks,
Kiran Rudramuni
QUalcomm Innovation Center

#8

Um, does that mean that I should not bother creating the logs and sending to Sivaram, because you are going to do that anyway?

If so, thank you!

It is amazing how well things work when you can communicate with the right people.

#9

Can you provide any indication of the timeframe for this? Or any suggestions about what to look at to get it working?

#10

Hi doitright
have you solved the problem with audio routing?

Regards