TiMidity++ AE

[xperia64]

Except when using gigantic sound banks in fluidsynth, I managed to control the skipping problem by increasing the delay between each song finished check to 1 second from 10 milliseconds and loading android supported song types into MediaPlayer directly from a path instead of a fileinputstream.

[xperia64]

Good news! I got TiMidity++ compiled into a working library with wave file output. It seems to be a lot faster than fluidsynth and sounds better than both fluidsynth and timidity. I still need to write a streaming output driver for android. Perhaps I'll also integrate libxmp as well to cover the subpar timidity++ amiga playback as I plan to completely ditch SDL and related libraries.
Fluidsynth vs TiMidity++ on a GBA midi file+soundfont on android (do I even need to say why TiMidity++ is better?):
Fluidsynth: https://db.tt/tgUJYd1A
TiMidity++: https://db.tt/gjz7GlRN

[xperia64]

We now have audio streaming, the hardest part was calling java from c (still not sure if I'm doing it properly) to pass byte arrays. After nearly 2 years trying to achieve this, I managed to do it in 2 days .

[Paul]

the hardest part was calling java from c (still not sure if I'm doing it properly) to pass byte arrays.

Working on the SDL2 upgrade (and updating the target for FrodoC64), I picked up a little experience with some of the pitfalls of JNI.  If you have the code posted somewhere, I'll take a look and see if I spot any potential snags.

[xperia64]

http://pastebin.com/44ahc97z

[xperia64]

Sorry to rant again, but the NDK is being very strange and obnoxious. For whatever reason, yesterday I compiled timidity++ and it had excellent performance. I made a backup of all of the JNI stuff, I think after I built the most recent test apk. The test apk has excellent performance when playing midi files, however all builds after have terrible performance. I can't figure out why. The md5sums of the libs as they are now and the libs in the apk are different, but have 10 different bytes (maybe packing into an apk changed a couple of things?). Perhaps I should just start over from git...
As TiMidity++ is GPL, I may as well post the source now if anyone wants to check it. https://db.tt/9ewNy9H3
Example of ndk weirdness: I'd change sample rate to 44100 on the NDK side but it still played at 48000. The only real changes I made from regular git is decreasing the voice count from 256 to 128 and changing resampling to newton. Unless newton finally kicked in with these newer builds and is producing the lag, I don't know what to make of it.

[littleguy]

Did you change NDK versions in the last 48 hours?

[xperia64]

Nope. Sticking with r8d, hasn't let me down before.

[xperia64]

Hmm, decided to re-port my changes to a fresh tar ball, and its still not great. However, I found out how to use the note-cutoff feature (like frameskip for audio) which greatly improves performance. Still, I wonder what I did the first time that made it run better... Perhaps it was the audio filtering...
Anyway, it doesn't sound as nasty, and works pretty well on my N7. It crashes on my S2 for some reason with error "jit unchain for all threadid=XX".

[xperia64]

Well well. Apparently I need a huge audio buffer for this and 1KB was not cutting it. 96000 bytes works great even on lower clockspeeds with my N7 for intense midi processing.

[xperia64]

Ok, got it working fine on my S2. Now I'm trying to tackle a problem with the volume. TiMidity++ was designed to:
Load an unchanging array of songs all at once
Play all of them with internal next and previous commands
Completely quit and repeat.

As most music players don't want the entire app to quit after finishing some songs, I'm passing an array of a single song to the timidity_play_main function, letting it play and "quit", then load the next song as an array and repeat. It works decently, however when I change songs, the volume of the new song is too loud and peaks on one or more track. It doesn't peak when I load two songs "properly" in a single array. I could do something with an interface I guess, but I'd rather be able to call timidity_play_main multiple times.
Source (JNI only): https://db.tt/m3JzGLqD

[xperia64]

I suppose I answered my own question. Interfaces are the way to go. timidity_play_main should never be called more than once, it never ends well.. Now that the clipping issue is taking care of and I have a much nicer way to interface with TiMidity++'s core, I can start the polishing phase.

[Shannonbip]

that I interrupt you, but, in my opinion, there is other way of the decision of a question.

[Chinaprift]

And you have understood?

[Chinaprift]

You are certainly right. In it something is also to me this thought is pleasant, I completely with you agree.