Repository navigation
Conversation
|
Thanks. Let me sit on this and consider it. I'm not immediately against it or anything. A question. This comes from my own ignorance - with the |
|
Yes, that's correct. Do you think those updates would work better? I can't figure out why the Android build keeps failing. Sorry for all the testing - I'm not very experienced with C. |
|
I've had more of a look at this and have decided not to accept it. I didn't notice this before, but this PR depends on C++. miniaudio is a C library. This would result in the AAudio backend having different behaviour depending on whether or not it's a C++ build or a C build. This is a maintenance nightmare and I will not be accepting it. If you need this functionality I'd recommend you maintain your own branch. |
This is a draft proposal for retrieving and enumerating audio devices on Android using the JNI interface. It's not ready for merging yet, but I'd like to start a discussion about this approach.
What are your thoughts on using the JNI interface to get the device list?
Known issues that need addressing:
Default Device Selection Problem: Currently, the default device is determined by its index position in the list, since there's no direct way to get the preferred audio route. The only alternative would be to:
However, I don't think this approach is ideal. An alternative would be creating a priority system based on device type (e.g., speaker > bluetooth > built-in).
Missing device type information: The current implementation doesn't expose the device type, which is crucial for disambiguation. Many devices show multiple entries with the same name (typically the phone's model name) for different audio outputs like built-in speaker and built-in earphone, making them impossible to distinguish without type information.