Speed issues with complex songs

[mills32]

Hi!

The board is working perfect!, I started to rip a lot of dro and imf to test and I found this issue. I tested this in imf player (because it was a bit simpler than dro).

Some complex songs are not playing at constan speed, I think it is because they use variable delays and the playinf is not returning the correct delay.

Removing the "round" from this line seems to (nearly) fix the problem, but still some variable speed. [code] return wait * (1000 / imfSpeed); [/code]

I thought arduino might be too "slow" to play complex songs, but that's not the case, because I used an external constant delay in the loop function, and the speed was constant (but of course the songs play incredibly fast).

Here is a song that has issues, it will play slower when all opl channels are being used. bpast.zip

[ghost]

Just to confirm, are you using PlayIMF.ino?

I'm not the creator of the board or that code, but based on issues I ran into when creating examples/SerialIface, here are some possible causes to investigate:

• (Most likely in my opinion) Is playback being blocked down by SD card I/O? I found that for playing more complex tunes via the serial interface, I had to increase the serial buffer size to 512 bytes. Maybe PlayIMF.ino could buffer SD card reads ahead into RAM?
• Use microsecond resolution delay (delayMicroseconds) in addition to millisecond (delay)?
• Won't cause variable speed playback, but wrong speed playback: IMF frequency varies per file, but is not encoded in the file itself - http://www.shikadi.net/moddingwiki/IMF_Format
• Is the delay being applied in the correct place (before vs after a note)? If I remember rightly, this was only an issue for VGM, not IMF though.

[mills32]

Yes, I'm using PlayIMF. The sd speed is way faster than the songs need... So fast you can set a short delay in the loop, and you'll hear a 1 minute song in a few seconds, (and i'm preety sure it is not skipping data because I know the songs very well :) ).

I think the issue is the time resolution, so i'll try using the delayMicroseconds and tell you if that fixes it.

Thanks.

[DhrBaksteen]

The problem is that the IMF and DRO examples are not taking into account the time that was spent on IO so when a lot is happening the delay will be too long. It's just being lazy coding it :). I already have the examples fixed locally and I was saving them up to push with an upcoming update of the library. I can push these separately when I get home in a few hours

[mills32]

That's cool, thanks.

[mills32]

I'll then close the issue.