New PND with a recent update from the author @8bitbubsy , this release is the Beta 130, and probably is the latest for Pandora (sadly 
).
In the 130 release that i just released on the repo i included the new songs that the author added on the PC package, plus a new song "Homecoming.XM" that use 32 channels i found it on MODarchive.
With the new Beta 131 he implemented a new interpolation routine that use now a quadratic interpolation, this means more accurate sounds, but more CPU power is required, and sadly with the Pandora this is not enough for some XM mods that use 32 channels, and overclock does not help.
I haven't done so much of tests but from what i ear there are some difference from previuos release and the Beta 131. I someone want to test i could upload a PND of this beta131. Let me know.
Thanks
).In the 130 release that i just released on the repo i included the new songs that the author added on the PC package, plus a new song "Homecoming.XM" that use 32 channels i found it on MODarchive.
With the new Beta 131 he implemented a new interpolation routine that use now a quadratic interpolation, this means more accurate sounds, but more CPU power is required, and sadly with the Pandora this is not enough for some XM mods that use 32 channels, and overclock does not help.
I haven't done so much of tests but from what i ear there are some difference from previuos release and the Beta 131. I someone want to test i could upload a PND of this beta131. Let me know.
Thanks
this release is the Beta 130, and probably is the latest for Pandora (sadly
what is the reason for being the last pandora version? just this interpolation?
beside that, release b131 and 132 don't seem to be too demanding for the pandora new feature wise.
I mean, a biqubic interpolation is not that demanding... and the interpolation routine should be replaceable quite easily... (back to linear interpolation or no interpolation)
(beside I recommend fourier-interpolation anyway
)EDIT:
I took a look into the source code of 132: there is a config option to disable interpolation, then newer versions should work also with the pandora (if set as default off)
also the interpolation code seems to be localized as macro at "src\ft2_mix_macros.h" line 64
as INTERPOLATE16 and INTERPOLATE8 which can be most likely easily replace by linear interpolation macros from earlier versions (don't have one for checking)
Last edited:
Thanks for looking at the code, i didn't have some free time to look at it.
Interpolation could also be disabled on the options menu...but i look at the code and i'll try to compile and test this recent revisions.
Now for Pandora users ...this is the release 131 without any modifications to the code....http://ge.tt/2poc9Hu2
Please test with your Pandora and let me know your impressions on how it play with XM modules...for me it's sound a bit weird...but maybe it's only me and my ears.
Advice...please use good earphone to test as the speakers of Pandora are not the best for this kind of tests.
Also please don't upload this PND to the repo.
hello farox, i looked if I have some older version of ft2 to find replacement code for the bicubic interpolation: but the newest source code i have ist ft2-b88... incompatible.
Have you newer one?
(And in general I think we should mirror the source code versions at github....)
I have some of the past release on my Drives...anyway source code are inside at every pnd i released (just open them with 7Zip for example), plus i'm not familiar with Git/Github, it's something that i like to master someday...but free time...
8bitbubsy
Still Fresh
I have now added a compile flag (-DLERPMIX) that will use the old fast linear interpolation routine (instead of quadratic interpolation), for slower devices like Pandora.
Hopefully Farox will compile beta #132 for the Pandora soon with this flag in the compiler script.
EDIT: Try to compile the program as 64-bit if Pandora supports that, the mixer can benefit from it if the CPU can't do fast 64-bit mul/shift stuff in 32-bit (which x86 can).
Hopefully Farox will compile beta #132 for the Pandora soon with this flag in the compiler script.
EDIT: Try to compile the program as 64-bit if Pandora supports that, the mixer can benefit from it if the CPU can't do fast 64-bit mul/shift stuff in 32-bit (which x86 can).
Last edited:
levi
Still fresh, damnit!
The Pandora (and the Pyra for that matter) use a 32 bit processor, but if my understanding is at all right, it can do 64-bit multiplies using NEON SIMD floating point ops even on single data points with a 0 exponent (so you get the full 64 bits as integers).
8bitbubsy
Still Fresh
The question is if the C compiler will translate c = ((int64_t)a * b) >> 32; into using fast 32-bit integer opcodes like on x86. This is used in the inner mixing loop, so it's very speed critical. It's done twice for stereo.
On x86 (32-bit) it would convert into a single imul, then instead of the 64-bit shift it just takes the higher 32-bit part of the result which resides in a specific 32-bit register after the multiplication.
8bitbubsy
Still Fresh
Yeah, just go to Config -> I/O Devices (selected by default), and uncheck "Interpolation". This will save to the config when you close the program.
levi
Still fresh, damnit!
I couldn't tell you the state of the art, but when exophase was doing this a couple of years ago, he needed to inline asm to do it.
8bitbubsy
Still Fresh
I disassembled the Pandora port now, and apparently it uses the SMULL ARM instruction (which takes 32-bit input and does a 64-bit multiplication), so this should not be a speed issue at all.
This instruction: http://www.keil.com/support/man/docs/armasm/armasm_dom1361289902800.htm
EDIT: Also noticed that it calls __udivsi3 (some GCC specific routine) in the mixer, which has an incredibly large amount of overhead. Something is not translating correctly to native opcodes here, but it's not in the inner mixing loop at least.
Seems like the overhead from the quadratic interpolation is what makes it choke. The video rendering method used in the clone can also be somewhat taxing on the CPU.
This instruction: http://www.keil.com/support/man/docs/armasm/armasm_dom1361289902800.htm
EDIT: Also noticed that it calls __udivsi3 (some GCC specific routine) in the mixer, which has an incredibly large amount of overhead. Something is not translating correctly to native opcodes here, but it's not in the inner mixing loop at least.
Seems like the overhead from the quadratic interpolation is what makes it choke. The video rendering method used in the clone can also be somewhat taxing on the CPU.
Last edited:
levi
Still fresh, damnit!
Ah, yeah SMULL now I read it appears to spit out both a low and high 32-bit register, giving a 64 bit result. That seems to be a relatively recent invention; it's not in the ARMv6 instruction set as far as I can tell, and I think the last time I tried writing ARM code natively it'd have still been ARMv3. I should really check what documents ARM have released thus far for their 32-bit cortex-A products; I only have a trm which gives me instruction timings but doesn't actually explain the difference between the different multiply operations.
Sorry for not reply here but my Internet provider didn't give me the possiblity in the past 2 days.
I have compiled a 132 version with (-DLERPMIX) option but in my opinion it did play a little bit worse than version 130 with XM mods that use 32 channels...but more details after work ( ...i hope)
8bitbubsy
Still Fresh
That's really odd, it should be identical to version 130 when it comes to the mixer (when you pass -DLERPMIX). Anyway, what toolkit do you use to compile it for the Pandora? I also need your buildscript. The reason is that I see that some of the code in the mixer is compiled into using a really slow GCC alternative function for 32-bit unsigned division, this has to be fixed ASAP for performance reasons. If I get to use the same build environment you use, I can change some code until it doesn't call that __udivsi3 function anymore.
EDIT: If you could record the 32-channel song playing with the new -DLERPMIX compile and upload it, it would be great.
EDIT: If you could record the 32-channel song playing with the new -DLERPMIX compile and upload it, it would be great.
Last edited:
To compile i use the GCC contained on @ptitSeb Codeblocks PND (a beta release of 2017 that have GCC 7.1.0 inside) available here https://pyra-handheld.com/boards/threads/ptitsebs-beta-lair.77439/
the build script is contained inside the PND (under source dir you will find "make-linux.sh") anyway this is the content of the unreleased version 132 (the old ones are the same but without -DLERPMIX):
Code:
gcc -D__LINUX_ALSA__ -DLERPMIX src/rtmidi/*.cpp src/gfxdata/*.c src/*.c -lSDL2 -lpthread -lasound -liconv -lstdc++ -lm -Wshadow -Winit-self -Wall -Wno-implicit-fallthrough -Wno-unused-result -Wno-strict-aliasing -Wextra -Wunused -Wunreachable-code -Wswitch-default -mcpu=cortex-a8 -mfpu=neon -mneon-for-64bits -mvectorize-with-neon-double -Ofast -o release/other/ft2-cloneAbout recording a 32 channel song...i'll do it tomorrow.
Thanks
8bitbubsy
Still Fresh
Ah, you're compiling natively on the Pandora itself? Then I may be out of luck, I don't own one. Surely there must be a way to compile for the same CPU on cross-platform (f.ex Windows)?
ptitSeb
Serial Porter
You can try to use this script: http://ptitseb.openpandora.org/crosscompilemaker.sh to build a cross-compile environnement in a Linux box.
8bitbubsy
Still Fresh
GCC 4.9.3.. This is so old that it most likely will not generate the same code as the farnox' port of the software (which is important so that I can make the fix). Anyway, this is getting pretty complicated and difficult at this point, so I think there's nothing reasonable for me to do.
