in the very least, the wav tracks should contain a 'relative time from start of song' field for each frame, that contains as fine grained, even nanosecond timestamp, so every N seconds ( with it's process/thread time ) or so the app playing all the tracks just checks that field to see whether some track is slightly off-time and then linearly adjusts that track...
it can be seen as a problem similar to this:
Genetic and Ant Colony Optimization Algorithms
www.codeproject.com
"
CMemDC is a class used for double buffering. This is a technique used in computer animation to avoid screen flicker, which was a major problem due to the fact that the screen is updated (repainted) several times each second. The technique used here is to create an off-screen buffer to which the image is drawn. The final image is then copied to the screen"
but for audio.
Yes, there may be threads, thank you, but callbacks can do much more, one may be able to have only one buffer filled and sent to the audio device...
Also for reference,
https://www.einval.com/~steve/software/JTE/
"
parallel-sums is a simple extra utility to generate checksums quickly and efficiently, reading file data only once and calculating checksums using multiple algorithms in parallel using threads."
Only this app is uniquely positioned to add an ECHO feature ( with configurable delay ) for a single track or few tracks.
Also there is this something I read somewhere that all MP3 players on Android are not using the floating point functionality. You'll find the build flags in my app to enable that if required at all:
Android and Windows Mobile Developers - The Largest Community for Phone Hacks and Development of Apps
forum.xda-developers.com
