Author Topic: TiMidity++ AE  (Read 22944 times)

Offline xperia64

  • Developer
  • double
  • *****
  • Posts: 591
    • View Profile
    • My Apps
Re: TiMidity++ AE
« Reply #30 on: October 28, 2013, 09:44:10 PM »
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.

Offline xperia64

  • Developer
  • double
  • *****
  • Posts: 591
    • View Profile
    • My Apps
Re: TiMidity++ AE
« Reply #31 on: January 12, 2014, 05:34:57 PM »
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

Offline xperia64

  • Developer
  • double
  • *****
  • Posts: 591
    • View Profile
    • My Apps
Re: TiMidity++ AE
« Reply #32 on: January 13, 2014, 06:57:52 PM »
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 :P.
« Last Edit: January 13, 2014, 09:10:26 PM by xperia64 »

Offline Paul

  • Administrator
  • double
  • *****
  • Posts: 3473
  • Developer
    • View Profile
    • PaulsCode.Com
Re: TiMidity++ AE
« Reply #33 on: January 13, 2014, 09:48:16 PM »
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.
Device: Samsung Galaxy Nexus i515
CPU: TI OMAP4460, 1.2 GHz (dual core, ARM Cortex-A9)
GPU: PowerVR SGX540, 307 MHz
RAM: 1 GB
Resolution: 720 x 1280
Rom: omni-4.4.4-20141014-toro-FML KitKat 4.4.4, rooted

Device: Eee PC 1015PEM
CPU: Intel Atom N550, 1.5 GHz (dual core, x86)
GPU: Intel GMA 3150, 200 MHz (dual core)
RAM: 2GB
Resolution: 1024 x 600
Rom: android-x86-4.3-20130725 Jelly Bean 4.3, rooted

Offline xperia64

  • Developer
  • double
  • *****
  • Posts: 591
    • View Profile
    • My Apps
Re: TiMidity++ AE
« Reply #34 on: January 14, 2014, 03:33:02 PM »

Offline xperia64

  • Developer
  • double
  • *****
  • Posts: 591
    • View Profile
    • My Apps
Re: TiMidity++ AE
« Reply #35 on: January 14, 2014, 07:38:05 PM »
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.
« Last Edit: January 14, 2014, 07:48:38 PM by xperia64 »

Offline littleguy

  • Developer
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: TiMidity++ AE
« Reply #36 on: January 14, 2014, 09:07:07 PM »
Did you change NDK versions in the last 48 hours?
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline xperia64

  • Developer
  • double
  • *****
  • Posts: 591
    • View Profile
    • My Apps
Re: TiMidity++ AE
« Reply #37 on: January 14, 2014, 09:13:04 PM »
Nope. Sticking with r8d, hasn't let me down before.

Offline xperia64

  • Developer
  • double
  • *****
  • Posts: 591
    • View Profile
    • My Apps
Re: TiMidity++ AE
« Reply #38 on: January 15, 2014, 06:15:08 PM »
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".

Offline xperia64

  • Developer
  • double
  • *****
  • Posts: 591
    • View Profile
    • My Apps
Re: TiMidity++ AE
« Reply #39 on: March 18, 2014, 07:05:10 PM »
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.

Offline xperia64

  • Developer
  • double
  • *****
  • Posts: 591
    • View Profile
    • My Apps
Re: TiMidity++ AE
« Reply #40 on: March 22, 2014, 10:22:15 AM »
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

Offline xperia64

  • Developer
  • double
  • *****
  • Posts: 591
    • View Profile
    • My Apps
Re: TiMidity++ AE
« Reply #41 on: April 02, 2014, 06:50:02 PM »
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.