what is the reason for being the last pandora version? just this interpolation?this release is the Beta 130, and probably is the latest for Pandora (sadly ).
Thanks for looking at the code, i didn't have some free time to look at it.I took a look into the source code of 132: there is a config option to disable interpolation,
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.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.
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.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).
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.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.
Sorry for not reply here but my Internet provider didn't give me the possiblity in the past 2 days.Hopefully Farox will compile beta #132 for the Pandora soon with this flag in the compiler script.
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/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.
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-clone