Please fix the formatting first as I mentioned before, otherwise it's hard to read the diff.
-1 signals that there is actually no synchronizer working (that's what the DefaultSynchronizer does). Coreaudio and jack do have proper synchronizer support, so they are supposed to return 0 or…
aud Python module instance methods are documented as classmethods
I have reverted changes in Audaspace, I am trying to resolve some build issues on Windows at least still.
Great! I assume once the build issues are resolved, the changes to audaspace's…
Please follow the code style of audaspace and do not apply Blender's clang format in this file. This leads to way too many changes in this file. Audaspace has it's own clang format changes, but you should only format actually changed code.
As I've written on developers.blender.org before accepting this patch I would like any changes to audaspace reverted. Everything necessary is in there already (in upstream audaspace and also ported to blender) and we need fftw3f (the float version not the double version) as a new dependency, since using fftw3d (the double version) is unnecessary here. Afaik, it is possible to have both versions of the library in one project. I've stated a couple of times already on developers.blender.org that the package maintainers have to be contacted to get fftw3f in.
I've added two name change suggestions, just fixing their styling.
Hey, sorry for taking some time to review this, I've been quite busy recently. I have looked over the code changes now, primarily in audaspace and added corresponding comments. I also briefly looked over the Blender changes, which look fine to the extent that I can judge them, maybe @Sergey wants to take a closer look there.
Likely a bug: Rather than having the fps duplicated here, please add a std::shared_ptr<SequenceData> and get the fps from there. This way, it will be updated when Sequence::setFPS is called which happens when the FPS in blender are changed!
Since this is just an integer loop, the fractal part of seek_frame is not considered. For more accurate seeking, I recommend to still consider it though.
Please rename write_range similarly to the other API functions that call it, so that its also clear from the name that it writes the same data into the range and doesn't get the full data for the range in the parameters. I.e. it repeats the data found in the parameter rather than expecting a bigger block of data that may differ all the way from start to end.