USB Microphone Support running Android P preview


#1

I have received the device and need to run our software on it. This is the first board I have had running android. From what I see of the specs, there is no Audio input. From what I read, android has been capable of USB microphone audio since 5.0. From the Docs page, I see in the OPTIONAL sections, a mention of Mezzanine expansions. If I get the Audio Mezzanine Board, https://www.arrow.com/en/products/114990332/seeed-technology-limited ?

Thank you for your time!

Board based on the Kirin 970 - HI3670 Application Processor
More info: http://www.96boards.org/product/hikey970/ (Website coming soon…)


#2

Technically, Android has ALWAYS been capable of USB audio input, if you supplied it with a HAL that would open the USB ALSA device. What they added in 5.0 was a universal USB Audio HAL.

The audio mezzanine specifically is for the dragonboard 410c, though should also support audio features of the dragonboard 820c. It does NOT use the i2s pins of the LS connector, but rather it uses the custom audio header that is NOT part of the 96boards spec and is only available on the two dragonboard units. It will NOT provide audio input for the hikey/960/970.

That means that your two options will be either USB or an i2s device, like this; https://www.adafruit.com/product/3421 – note that the board says 3.3 on it, but if you apply 1.8v there, you can wire the board directly into the i2s pins of the LS connector and it should work.

Wire it like this;
SEL: floating unless you are using TWO of these boards for stereo, then one floating, other HIGH (1.8v).
LRCL: 96boards LS pin 16
DOUT: 96boards LS pin 22
BCLK: 96boards LS pin 18
GND: 96boards LS pin 1, 2, 39, or 40
3V: 96boards LS pin 35 (1.8V)

*** CAUTION: Make absolutely sure that you don’t get the “3V” (1.8v) connected to the wrong pin. Across the plug you have 8-18 volts, and right beside it, you have 5v. Test the power with a voltmeter before connecting. If you get the wrong wire, you can damage both the microphone, AND the SBC.


#3

First, thank you so much for this detailed explanation and for your time. You mentioned I have two options, USB or an i2s device. What exactly do you mean by USB? A USB Sound card or USB Mic? I have both the Blue Yeti and the Blue Snowball mics. but plugging them into either of the USB - A seems to power the device, but yield no audio when running my application. The same Java / Android application records and recognizes well on standard android devices, so I assume it should work on this device fine after I can get some input.

Thanks again!


#4

Also, any idea why the USB - C on the side doest seem to work? The back one works.


#5

I’m not familiar enough with the 970 (I don’t have one) to say why the side usb isn’t working.

A “usb microphone” is a USB sound card. Presumably, one that only has a capture path and not a playback path.

Could you give it a try with something more common than those two microphones? I had a brief look at the manufacturer’s website, and I get the feeling that they are the type of outfit that prefers proprietary everything rather than leveraging standards. A lot of “proprietary sound” hardware manufacturers will implement a custom protocol that runs between their “software DSP + driver” package, and the hardware. In the end, it would not surprise me ONE BIT, if those devices are not supported by ALSA.

You will need to check if there is an ALSA device created when you connect them. Boot the hikey with the microphone UNPLUGGED, then check the contents of /sys/class/sound/, then plug it in, then check the contents of that directory again. If something new appeared in the directory, then ALSA has identified the device and added it.

Also check what spills out of “logcat” and “dmesg” when you plug in the card. Those can give you important clues about what is happening (if anything). If everything looks like it is working correctly, then you need to check the mixer settings. You will need to use “tinymix” for that, and I don’t think its built by default, so you’ll need to build it yourself. It should be enough to run “make tinymix” from the android source tree (after configuring it for your device) to build the tinymix binary, which will end up somewhere in your out/ directory. Just copy that to your device’s system partition and set the permissions.

If kernel checks out, try capturing some sound using “tinycap” (same thing goes for building it as for tinymix). If that checks out, but nothing captures in Android, then you need to look at the USB audio routing on Android. Its possible that they haven’t set that up [/correctly] yet.


#6

Thank you again for your time!

So watching LOGCAT, while plugging any USB mic in, thus far, UsbHostManager adds the device. Here is the output. When I unplug it UsbAlsaManager reports removing the device. To me this seems like ALSA knew it existed, but the contents of /sys/class/sound never increases or decreases when connecting and disconnecting the device. I also tried a USB to 3.5mm which it recognized, but again. no audio input.

Does this make you think it is indeed a USB Audio routing issue like you mentioned near the end of your last post? My logcat and dmesg are posted below.

LOGCAT

07-26 04:00:37.620 3200 3409 D UsbHostManager: Added device UsbDevice[mName=/dev/bus/usb/001/017,mVendorId=3468,mProductId=5,mClass=0,mSubclass=0,mProtocol=0,mManufacturerName=BLUE MICROPHONE,mProductName=Blue Snowball,mVersion=1.16,mSerialNumber=201305,mConfigurations=[
07-26 04:00:37.620 3200 3409 D UsbHostManager: UsbConfiguration[mId=1,mName=null,mAttributes=128,mMaxPower=50,mInterfaces=[
07-26 04:00:37.620 3200 3409 D UsbHostManager: UsbInterface[mId=0,mAlternateSetting=0,mName=null,mClass=1,mSubclass=1,mProtocol=0,mEndpoints=[]
07-26 04:00:37.620 3200 3409 D UsbHostManager: UsbInterface[mId=1,mAlternateSetting=0,mName=null,mClass=1,mSubclass=2,mProtocol=0,mEndpoints=[]
07-26 04:00:37.620 3200 3409 D UsbHostManager: UsbInterface[mId=1,mAlternateSetting=1,mName=null,mClass=1,mSubclass=2,mProtocol=0,mEndpoints=[
07-26 04:00:37.620 3200 3409 D UsbHostManager: UsbEndpoint[mAddress=130,mAttributes=13,mMaxPacketSize=100,mInterval=1]]
07-26 04:00:37.620 3200 3409 D UsbHostManager: UsbInterface[mId=1,mAlternateSetting=2,mName=null,mClass=1,mSubclass=2,mProtocol=0,mEndpoints=[
07-26 04:00:37.620 3200 3409 D UsbHostManager: UsbEndpoint[mAddress=130,mAttributes=13,mMaxPacketSize=200,mInterval=1]]
07-26 04:00:37.620 3200 3409 D UsbHostManager: UsbInterface[mId=2,mAlternateSetting=0,mName=null,mClass=3,mSubclass=0,mProtocol=0,mEndpoints=[
07-26 04:00:37.620 3200 3409 D UsbHostManager: UsbEndpoint[mAddress=135,mAttributes=3,mMaxPacketSize=16,mInterval=2]]]]
07-26 04:00:37.622 3200 3409 I DescriptorParser: Unknown Descriptor len:14 type:0x24
07-26 04:00:37.622 3200 3409 I DescriptorParser: Unknown Descriptor len:14 type:0x24
07-26 04:00:37.622 3200 3409 W DescriptorParser: Unrecognized Audio Interface l:14 t:0x24
07-26 04:00:37.622 3200 3409 I UsbHostManager: ---- isHeadset[in:false , out:false]
07-26 04:00:37.622 3200 3409 I chatty : uid=1000(system) UsbService host identical 4 lines
07-26 04:00:37.622 3200 3409 W DescriptorParser: Unrecognized Audio Interface l:14 t:0x24
07-26 04:00:37.664 3200 3285 D EventHub: No input device configuration file found for device ‘BLUE MICROPHONE Blue Snowball’.
07-26 04:00:46.355 2823 2823 W wificond: Skip scan ssid for single scan: KadhoNet_5G, KadhoNet
07-26 04:00:51.627 3200 4820 D WificondControl: Scan result ready event
07-26 04:02:06.714 3200 3285 I EventHub: Removing device ‘/dev/input/event2’ due to inotify event
07-26 04:02:06.769 3200 3409 I UsbAlsaManager: USB Audio Device Removed: null

///////////////////////////////////////////////////////////
DESMG

[ 4722.065281] usb 1-1.2: new full-speed USB device number 17 using xhci-hcd
[ 4722.172172] usb 1-1.2: New USB device found, idVendor=0d8c, idProduct=0005
[ 4722.179090] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4722.186468] usb 1-1.2: Product: Blue Snowball
[ 4722.190872] usb 1-1.2: Manufacturer: BLUE MICROPHONE
[ 4722.195945] usb 1-1.2: SerialNumber: 201305
[ 4722.232160] input: BLUE MICROPHONE Blue Snowball as /devices/platform/soc/soc:hisi_dwc3/ff100000.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1.2/1-1.2:1.2/0003:0D8C:0005.0017/input/input11
[ 4722.249105] hid-generic 0003:0D8C:0005.0017: input,hidraw2: USB HID v1.00 Device [BLUE MICROPHONE Blue Snowball] on usb-xhci-hcd.0.auto-1.2/input2
[ 4811.349050] usb 1-1.2: USB disconnect, device number 17
[ 5034.026139] type=1400 audit(1532577445.521:366): avc: denied { create } for pid=56 comm=“kdevtmpfs” name=“015” scontext=u:r:kernel:s0 tcontext=u:object_r:device:s0 tclass=chr_file permissive=1
[ 5034.043417] type=1400 audit(1532577949.377:367): avc: denied { syslog_read } for pid=6879 comm=“dmesg” scontext=u:r:shell:s0 tcontext=u:r:kernel:s0 tclass=system permissive=1

I will try tinymix and tinycap like you suggested, but wanted to post my preliminary findings.

Thank you again!


#7

Also, I read somewhere on Androids site, that usb-audio doesnt work with developer mode on. Have you heard anything about this? The device came with Android P Preview, and I think developer mode is on by default.


#8

LOL, no.
If you look in DEVELOPER OPTIONS (this is a sub-menu in the settings menu), it has a button that allows you to disable USB Audio Routing, but it is not set by default. You would actually have to go in there and check the box manually. This option has nothing at all to do with how you build Android. All Android builds have this menu, except if they’re butchered by a bad hardware vendor.

Also, this has nothing to do with your problem.
This does, however;

07-26 04:00:37.622 3200 3409 W DescriptorParser: Unrecognized Audio Interface l:14 t:0x24
07-26 04:00:37.622 3200 3409 I UsbHostManager: ---- isHeadset[in:false , out:false]

Note the in:false. If the kernel properly identified your hardware, that should say in:true.

And I’m not seeing anything at all in your dmesg excerpt about audio, and you haven’t shown the contents of the path I asked you to check.

You need to try a proper, generic USB sound device. I have a feeling that your fancy microphone may be just an overpriced paper weight.


#9

/sys/class/sound:
card0 controlC0 pcmC0D0p pcmC0D1c pcmC0D1p timer

Lol yah i figured out the developer mode question. Desperation can sometimes breed some dumb questions. Thanks again. Ill be trying a different MIC in the morning, but this worries me as i see videos of others using these very mics with android devices.

You rock!


#10

That’s definitely not showing a usb alsa device. What you got there is the cpu. C0D0 is the i2s port routed to the HDMI and Bluetooth chips. C0D1 is routed to the low speed expansion port.


#11

Not sure what’s going on but /proc/asound (and especially cards and devices) are more human friendly than /sys/class/sound so less likely to be any mistakes.

It might also be useful to connect the 'ball to a desktop Linux machine and compare the dmesg and /proc/asound differences. Whilst there are a tiny number of USB devices that don’t use the USB audio class protocol these devices are typically both old designs and expensive (e.g. pro or semi-pro audio kit that was early to market). I really would expect this to be a combo device (audio class device for audio plus HID device for buttons).

Finally this is potentially a dumb question (I don’t do a lot with Android) but are we sure that microphone only sound cards are handled by the Android HAL? They are relatively uncommon, especially for typical phone/tablet use cases.