Audio and Microphone on Android OS for DragonBoard™ 410c

  1. When will analog expansion header be working for the Android OS (for both audio and mic)?

  2. When will USB support audio and microphone?

Thank you!


Have you been able to get ANY sound output from this device?
I’ve tried hooking up to speaker, headset, AND HDMI for sound… nothing comes out.


There is nothing in the release notes that indicates that sound isn’t fully operational.


Nevermind that… have sound now on the hdmi.


Oh you’ve got to be kidding me… sound works when display is 1080p, but not 720p.


Just so I don’t pollute this thread for a marginally unrelated problem, I have solved that problem by making some kernel changes. If anybody needs the changes, just ask.


Hi doitright,

can you please provide me kernel changes for sound issues.



Ok, I will when I get home tonight.


sdrobertw: have you looked at the mixer file?
*** that is the “default” 8916/sbc mixer file, BUT, not the same as the one that you get with the actual device.


Also can be found as a patch within this archive;

In particular, notice that speaker-mic and handset-mic are both (default) set to adc1 (analog-to-digital converter #1). headset-mic is set to adc2. There are THREE microphones, also adc3.

Note that MIC1, which probably corresponds to adc1, is just a point on the BACK side of the board. So if you select speaker-mic or handset-mic, it will NOT connect to mic2 or mic3 points on the audio header.

I think that to connect to adc2 (which is the pre-biased microphone connection), or to the stereo headset outputs, you need to trigger headset detect. Alternatively, you can remap around it such that speaker-mic and/or handset-mic refer to adc2.

To put this speaker/handset/headset stuff into context;
speaker = speakerphone. I.e., a voice call when a cellphone is held AWAY from your head.
handset = regular cellphone handset, i.e. hold a cellphone against your head.
headset = earphones+microphone plugged into a cellphone via a wire.
headphones = ??? Ok, on OUR mixer file, this appears to be sort-of like headset. This appears to be sending sound out to the headset outputs on the audio header AND the i2s on the low speed port (i.e., not the HDMI).

Also note that in that file, some of the RX/TX is a bit counterintuitive. From “our” point of view, you might assume RX = sound into the phone/sbc and TX = sound out from the phone/sbc. This is not always the case, since we might be looking at RX and TX from the point of view of the SoC receiving from and transmitting to the DSP (sound chip, which in this case is built into the PMIC)

Notice in that file that the path named “speaker” for THIS board, does not match the one on the CAF git server.

<path name=“speaker”>
<ctl name=“RX3 MIX1 INP1” value=“RX1” />
<ctl name=“SPK DAC Switch” value=“1” />

<path name=“speaker”>
<ctl name=“MI2S_RX Channels” value=“Two” />

What that means: The “speaker” output (RX!!!) on DB410c is actually being sent out as stereo i2s. In fact, it is being sent out to the adv7533’s input so that it can be added to the HDMI. Possibly also being sent out to the i2s pins on the low speed header.

Yep, I fully agree that these mixer files are a total nightmare.


Hi All,

USB microphone audio record has not been validated on the current Android release for 410c. It is being planned for September release.

Kiran Rudramuni
Qualcomm Innovation Center


I can’t be certain, but I suspect strongly that he is looking at USB just as a workaround for the audio header.

diff --git a/drivers/video/msm/mdss/adv7533_dsi2hdmi.c b/drivers/video/msm/mdss/adv7533_dsi2hdmi.c index 7397032..a9bb29a 100644 --- a/drivers/video/msm/mdss/adv7533_dsi2hdmi.c +++ b/drivers/video/msm/mdss/adv7533_dsi2hdmi.c @@ -240,6 +240,24 @@ static struct adv7533_reg_cfg tg_cfg_720p[] = { /* vbp 0x14 20 */ {ADV7533_CEC_DSI, 0x36, 0x01}, {ADV7533_CEC_DSI, 0x37, 0x40}, + /* Timing Generator Enable */ + {ADV7533_CEC_DSI, 0x27, 0xCB}, + {ADV7533_CEC_DSI, 0x27, 0x8B}, + {ADV7533_CEC_DSI, 0x27, 0xCB}, + /* Reset Internal Timing Generator */ + {ADV7533_MAIN, 0xAF, 0x16}, + /* HDMI Mode Select */ + {ADV7533_CEC_DSI, 0x78, 0x03}, + /* HDMI Output Enable */ + {ADV7533_MAIN, 0x40, 0x80}, + /* GC Packet Enable */ + {ADV7533_MAIN, 0x4C, 0x04}, + /* Colour Depth 24-bit per pixel */ + {ADV7533_MAIN, 0x49, 0x00}, + /* Down Dither Output 8-bit Colour Depth */ + {ADV7533_CEC_DSI, 0x05, 0xC8}, + /* ADI Required Write */ + {ADV7533_CEC_DSI, 0xBE, 0x3D}, /* Test Pattern Disable (0x55[7] = 0) */ {ADV7533_CEC_DSI, 0x55, 0x00}, /* HDMI disabled */ @@ -248,6 +266,7 @@ static struct adv7533_reg_cfg tg_cfg_720p[] = { {ADV7533_CEC_DSI, 0x03, 0x89}, };

+#if 0
static struct adv7533_reg_cfg tg_cfg_pattern_720p[] = {
{ADV7533_CEC_DSI, 0x1C, 0x30},
/* hsync and vsync active low /
@@ -292,6 +311,7 @@ static struct adv7533_reg_cfg tg_cfg_pattern_720p[] = {
{ADV7533_CEC_DSI, 0x03, 0x09},/
HDMI disabled /
{ADV7533_CEC_DSI, 0x03, 0x89},/
HDMI enabled */

static struct adv7533_reg_cfg I2S_cfg[] = {
{ADV7533_MAIN, 0x0D, 0x18}, /* Bit width = 16Bits*/
@@ -732,8 +752,8 @@ static int adv7533_probe(struct i2c_client *client_,
case ADV7533_VIDEO_480P:
case ADV7533_VIDEO_720P:

  •           ret = adv7533_write_regs(pdata, tg_cfg_pattern_720p,
  •                   ARRAY_SIZE(tg_cfg_pattern_720p));
  •           //ret = adv7533_write_regs(pdata, tg_cfg_pattern_720p,
  •           //      ARRAY_SIZE(tg_cfg_pattern_720p));
              ret = adv7533_write_regs(pdata, tg_cfg_720p,
              if (ret != 0) {


Can you tell us what other changes are being planned for the september release?

Maybe… fix the nav bar in 720p mode, and fix the audio routing so that hfp-client mode actually works?

Also, promote AUDIO_DEVICE_OUT_SPEAKER to highest priority in primary output;


primary {
sampling_rates 44100|48000

change to:

primary {
sampling_rates 44100|48000


we can definitely consider your suggestion to change AUDIO_DEVICE_OUT_SPEAKER priority in September update.

can you comment a little bit more on 720p navigation bar issue ? which monitor are you using to test this ?

There are some more optimizations for HDMI and other features that are planned for September Android release.

Kiran Rudramuni
Qualcomm Innovation Center


The nav bar issue is due to Android, not the panel. I am using!/7-open-frame-universal-HDMI-LCD-with-capacitive-multi-touch/p/21750207/category=3094861 – HOWEVER, the same thing happens with ANY HDMI monitor when the output resolution is set to 720p. I.e., you can reproduce it on a television.

To reproduce the issue, force it into 720p mode using;
fastboot oem select-display-panel adv7533_720p

NOTE: The FULL 1280x720 output IS appearing on the monitor. Nothing is being cut off or added.

When Android detects that the monitor is below a certain size, it enables a MOVABLE NAV bar. It does this in order to maximize the vertical working space on a small device in landscape mode by keeping the nav bar along a NARROW edge. Effectively, it means that on the DB410c with a landscape HDMI display, the nav bar will be vertical along the RIGHT side of the panel, just like it is on, for example, a Nexus 6.


****** THE PROBLEM!!!
Is that the BUTTONS aren’t present on the nav bar in this mode! The bar is there in the correct location, but the square/circle/triangle buttons are missing entirely.

If you plug in a mouse, you can drive the cursor into that region and it displays perfectly, so it isn’t a graphics mode issue. I’ve even tried clicking on the buttons where they are supposed to be, and… nothing.

The workaround I’ve been using has been setting the prop ro.sf.lcd_density to 160 in order to tell Android that the panel is large. This moves the nav bar down to the bottom and makes it functional, but (a) it would be much preferred to have the panel on the right side, and (b) CRITICALLY important to actually have the buttons present on the bar, © at that density, everything on the screen scales to be very inappropriately small.


Will be validating on a 720p display shortly, I think the below commands to set “qemu.hw.mainkeys=0” in build.prop
will help bring the buttons to foreground.

adb wait-for-device && adb root && adb wait-for-device && adb remount && adb wait-for-device
adb shell "echo ro.sf.lcd_density=240 >> /system/build.prop"
adb shell "echo ‘qemu.hw.mainkeys=0’ >> /system/build.prop"
adb shell sync

Kiran Rudramuni
Qualcomm Innovation Center


Hi Kiran,
Unfortunately, the change that you suggested had no impact on the problem. In fact, it doesn’t seem to do anything at all.

I believe that it is because it isn’t a question of whether or not the buttons are supposed to be present, but rather some issue with the actual xml layout that is being applied in this mode.


Hello doitright,

Apologies, you need to reboot the device after those commands. if it still isn’t working we will try to resolve it soon.

please use adb shell “echo ro.sf.lcd_density=160 >> /system/build.prop”
adb shell “echo ro.sf.lcd_density=180 >> /system/build.prop”

instead of 240

adb shell "echo ro.sf.lcd_density=160 >> /system/build.prop"
adb shell "echo ‘qemu.hw.mainkeys=0’ >> /system/build.prop"
adb shell sync
adb reboot

Also please “adb pull /system/build.prop”

and make sure there are no duplicate entries for ro.sf.lcd_density

Kiran Rudramuni
Qualcomm Innovation Center


I am aware that it needs to be rebooted before a change like that will take effect. Like I said, it had no impact on the problem.

If you provide your email address, I can send you a screen capture to more properly explain the issue.


With Local DSI display you can expect that behavior where the device has primary display which is LCD screen in portrait mode and when mirrored on HDMI screen and it would be like this: with landscape mode orientation change either using rotation APKs or with sensors you will see navigation icons. currently with HDMI as primary the icons are always on the bottom for lcd density 240/160/180

Kiran Rudramuni
Qualcomm Innovation Center