I think Android is kind of only allowed to see a virtual Chrome OS audio device so from the current implementation I guess this is expected.

This is limited because we don't trust android to route the users audio. Making the setting independent for each app is confusing as is allowing an app to override the system selection.

My understanding from https://groups.google.com/a/google.com/forum/#!topic/arcdogfooders-discuss/Vav878GbhFM was that there was an ongoing effort to expose the full device list to both WebRTC and Android apps. The WebRTC side was done in version 59 (per  bug 554168 ).

If having a concrete use case would help, this issue is blocking a DJ app I contribute to (under IARC) from launching on Chromebooks. The app needs to be able to send prequeue audio to one device (user-selectable, usually the headphone jack), and main audio to another (usually a USB DAC).

Any updates here? Even if internal audio sinks were reported as one device, there are a lot of use cases for treating external audio devices (especially USB) differently. I would expect Android to continue to route to the default virtual device unless the app explicitly calls AudioTrack.setPreferredDevice(AudioDeviceInfo).

I also don't understand why it would be confusing for Android apps to override the default device when WebRTC apps are able to.

Hi Josh, have you spoken to hadrosaur@ or donturner@ about this issue? They have been looking at pro audio use cases on Pixelbook recently.

I'll be working on various things in this area, but to be honest at the moment I'm not sure what all the requirements or priorities are, or how these could best be integrated with ChromeOS.

I will be in MTV next week and was planning to try and meet with hadrosaur and donturner to discuss - maybe you could join?

Happy to. Feel free to add something to my calendar.