lioncash/droidsound — comment on commit 5466893894d27fba84d59537128b34c21d87a811
File:  line 0
By alankila:

Lioncash kirjoitti 12.2.2012 kello 21.14:

> This isn't related to the commit itself, but for the player.
>
> I managed to solve the problem to the playback rate being so slow for some files in vgmstream with high sampling rates.
>
> However, this also breaks the Visualization View, which for some reason also manages to crash the whole player when any other view is used while the song is playing.
>
> I don't know how the FFT works, so I thought I would tell you before making any commits. In fact, I'll only commit it once I can do so without breaking anything, but.
>
> Here's an example of what I did:
>
> http://pastebin.com/G8qUuYdq

Fascinating. Why isn't the AudioTrack with constructor argument of framerate already working correctly? I must have misguessed the API somehow. I'll look into that also tomorrow.

> On line 229-234 specifically is the change that breaks everything.
>
> The breakage gives the error message:

You left it out, but I'm pretty sure it's going to be an array out of bounds in the FFT short array.

> I'm just wondering if there should be an extension method in DroidsoundPlugin.java that allows the plugins to manage playback rates themselves.
>
> So far, this is the only way I can think of that will get vgmstream tracks playing perfectly.

I know what the visualization's problem is. It will not work if the sample rate is too low, because it assumes for instance that 14900 Hz frequency (or so) will exist, and if it's beyond the nyquist of the sample stream, then it will calculate the bin index outside the FFT region. I must make this dynamic, or just set the bin frequency to zero if igoes past the end of the FFT array.

Also the visualizer has frame rate issues if the playback rate varies, as new updates are sent every 1024 frames of input, and that makes it time dependent (22050 = half the framerate from expected). I'll think something for the crash, and for this problem although to be honest I don't really mind if the visualizer is slower for low samplerate streams.

--
Antti