Comment by phkahler
8 years ago
How can you say that without knowing 1) what the app is and 2) what tools it was built with?
There's also the problem of ongoing maintenance on multiple platforms. In the best case, it was written with a dual platform toolkit (iOS and Android) and MS adds a 3rd platform to that toolkit to make it easy to port and maintain all three. Even if that were all true, it's won't be for every developer and you'll still have problems bringing people to the platform.
1) http://www.drumkit.co
2) Built in Objective-C with a custom audio engine in C++. Audio latency on Android was horrible at that time, MS was probably worse. It would have been a terrible app on those platforms if I did port it. This was before cross-platform toolkits existed. It needed to be a native app with low level access audio to hardware. I wasn't going to make an app where you tap a drum and wait 100ms to hear a sound.
> MS was probably worse.
Not that this counters anything you said nor that relevant to this topic, but as a nerd I am genuinely curious if this was true. I used to write lowlat audio stuff for iOS so I was well aware of the situation Android vs iOS (and because of my large interest in audio Android in general always makes me puke in my mouth a little -- like it is one of those neat little hidden indicators that while Apple is a hardware company, Google is fundamentally an ad company -- they really don't give a shit other than prioritizing ad delivery).
Anyway, Windows itself obviously has solid low-lat audio services, was it really that bad in the mobile stuff?
Not knowing much about the topic (but knowing a lot of an adjacent topic of getting NDK working for video+cv on Android) -- sometimes it comes down to documentation, existing examples, StackOverflow content, etc. Even if it is possible, if it isnt well documented, it doesnt matter.