Changed the Diff in order to address comments by Nexyon and ISS
Specially:

• removed EqualizerReader. All from Equalizer to ConvolutionReader
• constants and the leadership of creation and sizes, taken in the Blender part
• buffer of communication con Audaspace created in Blender part
• With a Selector, the user can create 1, 2 or 3 graphical band definitions
• with Python API, user can delele all the graphical band definitions, and create one by one
• changes in names of structs and functions suggested by ISS
• improvements and simplifications commented by ISS
• limited modifications to +/-30 dB and cut the data from the curve mappings to +/-30 db

I am happy with the code functionally as well, left mostly nitpicks and suggestions.

The audaspace side of the patch starts to look good, mostly there is only minor changes left I would say:

Sounds doesn't seem to play at all since 2.93 for me.

Fix a typo cleaning the patch

Changes to include comments by Nexyom and ISS.
Specially:

I am not sure how useful restriction of cache used for only short audio. It is not uncommon to work on a montage of multiple longer videos files: things like reels, tutorials, etc.

I just wanted to mention, that I will accept whatever solution you and @Joerg Mueller (nexyon) will agree on, and sequencer stuff looks mostly reasonable. Only thing that stands out a bit for me is soundeqs field of Sequence. It's not really bad to have this separated from image modifiers, but if there should be more sound modifiers, I think, that these should be wrapped in more generic struct(similar to image modifiers), but this is probably detail compared to actual sound stuff.

This looks better already.

Well, you could add a setting to automatically enable caching, when the audio files are shorter than a specific length. Another option instead of using caching is to use proxies like done for video. I.e., convert the audio streams of the video file to PCM/wav/uncompressed audio for immediate seeking without performance issues.

I've tried to address most of the suggestions by Nexyon, as long as I have could, so:

• I've encapsulated all the EQ creation in EqualizerReader
• Any time there is a change in the sound Strip, it is created a new definition in SequenceEntry, in order to be ready when SequenceHandle detects different status (the same way it is nowadays)

@Joerg Mueller (nexyon), Making sure the current state is documented is surely welcome. However, it is a bad design to task an editor to worry about identifying where and when to enable caching. The good design is when an editor is focused on the editing task, and the performance is ensured by the system.

I disagree: caching consumes way too much memory to enable it by default when scrubbing is enabled. I instead suggest to suggest in the documentation to enable caching for audio strips when necessary for performance.

In T97750#1352687, @Joerg Mueller (nexyon) wrote:

In conclusion: turn on caching if the performance of ffmpeg is not good enough for scrubbing.

@Sergey Sharybin (sergey) thanks, will commit fix then

@Bastien Montagne (mont29) Using DEG_id_tag_update_ex instead of BKE_sound_load is correct. The only thing is that flag should just be ID_RECALC_AUDIO. Basically you almost never want to use explicit ID_RECALC_COPY_ON_WRITE.

This call to BKE_sound_load looks horribly old (from 2008! code) and wrong to me in context of new evaluation with depsgraph, I would expect rather something like that here:

Ok, so everything pretty much works as expected.

For bisect I focused specifically on frame 429.

To me the video doesn't seem to have an issue for either, to be honest. The Blender 3.0 version just seems to have a little less performance, which could be caused by a variety of factors. I don't see how rBbdbc7e12a02e would cause it though. Could be a different ffmpeg version even or so, but I don't think that would have changed during your bisection @Germano Cavalcante (mano-wii)?

Not sure how active Joerg is.
@Sebastian Parborg (zeddb), do you mind giving some help here? :)

Bisecting, this problem had apparently been resolved in rBded68fb10275: VSE: Fix audaspace not reading ffmpeg files with start offset correctly,
but was reintroduced in rBbdbc7e12a02e: Audaspace: added audio file streams functionality..

Thanks for the report. I can confirm the problem. Tested on a macOS-12.2-arm64-arm-64bit 64 Bits

Improved with ideas and suggestions by ISS.

Can confirm

I have left few more comments, also noticed that in UI it displays string STEREO which could be Stereo instead - nicer formatting basically.

• one of your major concerns is related with the relation between Blender and Audaspace. Now, there is a fixed way of dealing with the sound: mono, pan , pitch always. They cannot be deleted or avoided because blender supposes that they are threre, and the interface Audaspace - Blender suppose that they are there

Updated with comments taken into consideration:

• moved info to bSound
• updated info when it is changed the source
• taken info from depsgraph updating of sequence / bSound

Nexyon,
the biggest difficulty with dealing with Blender-Audaspace integration is the storage of that Integration.

my first try was to create a function and it would "examine" de audio file any time it is needed. But I thought that that would be too much extra-work.
I was thinking about where to store the information, and as the first simple attempt I chose Sequence because it is accesed in the strip creation, and because in a video strip the FPS are studied only in the creation.

Thanks for patch, I think this is quite useful.

Hello,

first of all, thank you for your attention.

I'll try to address your concerns:

• I've tried to separate, data and relations with Blender in SequenceReader, and media or down level in SequenceHandle. But I understand that the creation of the "filter" would better in a specific "IReader"
• one of your major concerns is related with the relation between Blender and Audaspace. Now, there is a fixed way of dealing with the sound: mono, pan , pitch always. They cannot be deleted or avoided because blender supposes that they are threre, and the interface Audaspace - Blender suppose that they are there
• BypassReader has 2 goals: intercept the sound treatment, in order to detect when the system needs a change (enable / disable / change equalizer), and the second goal is to keep a static pipeline of sound treatment, but with the posibility of avoid one step. If there is no REader inside, the overwork is just "one if to check is it is dirty"
• FFT doesn't need big accuracy. The problem is that I wanted to show something that worked, before trying to ask someone to modify / include de version of FFTW for only "float"
• boost was used in a phase of the project for debuging. I should have removed it before

Hello Marcos!