Turns out we already support a lot more audio formats via the library libsndfile we use to reading them, like mp3 and Opus encoded Ogg files. We just needed to add the appropriate file filters in AudioFileBrowser.
Song export was overhauled too to support all these new formats and expose the compression level for FLAC and formats based on lossy compression. Instead of WAV, FLAC is now the new default format selected on first opening. The different WAV and AIFF options in the template combo box were dropped and replaced by a format combo box exposing only the available formats. The previous setup was outdated. In case someone really want to export to WAV that persons most probably do not want to do so with reduced sample rate and depth. For more concise files FLAC or lossy compression will be used.
[x] Fix Windows support.
Our AppVeyor Windows pipeline is failing on 192000kHz 8/16 bit depth .au exports.
On my local Windows machine I have veeery strange behavior. There I too see that some formats require longer export time and Third order polynomial interpolation is more costly than others. But for Third-88200-32.w64 the machine has a peak export time of 165.5ms (!) with parameter sets nearby still reaching 8.3ms and 4.5ms. But apart from this export time rarely scratches our maximum time of 3ms (TestHelpers::exportSongnMaxSleeps). But when changing position of .w64 in our list of supported formats and processing it first, there is no export that requires more than 0.2ms.
This seems like some sort of memory leakage in maybe libsndfile itself.
[x] Reduce unit tests. Checking all format and parameter perculations takes too much time. I just kept it in here till the Windows issue above is fixed.
About failure of full test on Windows
For reasons not yet clear to me, the full test fails on Windows with a "bad alloc" exception. Checking the memory required by the test process one can see that virtual memory is constantly increasing and physical one looks like an irregular saw pattern. The process is quite hungry for memory and at times the OS frees it. Though, at some point memory consumption seems to get too big and something in the stack get's killed.
The upper figure shows the export of a WAV file with 16 bit depth and 48kHz over and over again. The lower figure shows the same export but in addition waits 5 seconds between each export (giving the OS time to free memory.) For both trials the exceptions occurs at roughly the same point.
But the behavior above does not seem to be related to the audio export code. At least, virtual memory consumption also increases linear when running the whole XmlTest suite instead of the audio export and other platforms do not show this issue. Therefore, I would consider this "solved" for now.
Turns out we already support a lot more audio formats via the library
libsndfilewe use to reading them, likemp3and Opus encoded Ogg files. We just needed to add the appropriate file filters inAudioFileBrowser.Song export was overhauled too to support all these new formats and expose the compression level for FLAC and formats based on lossy compression. Instead of WAV, FLAC is now the new default format selected on first opening. The different WAV and AIFF options in the template combo box were dropped and replaced by a format combo box exposing only the available formats. The previous setup was outdated. In case someone really want to export to WAV that persons most probably do not want to do so with reduced sample rate and depth. For more concise files FLAC or lossy compression will be used.
[x] Fix Windows support. Our AppVeyor Windows pipeline is failing on
192000kHz8/16bit depth.auexports.On my local Windows machine I have veeery strange behavior. There I too see that some formats require longer export time and
Thirdorder polynomial interpolation is more costly than others. But forThird-88200-32.w64the machine has a peak export time of165.5ms(!) with parameter sets nearby still reaching8.3msand4.5ms. But apart from this export time rarely scratches our maximum time of3ms(TestHelpers::exportSongnMaxSleeps). But when changing position of.w64in our list of supported formats and processing it first, there is no export that requires more than0.2ms.This seems like some sort of memory leakage in maybe
libsndfileitself.About failure of full test on Windows
For reasons not yet clear to me, the full test fails on Windows with a "bad alloc" exception. Checking the memory required by the test process one can see that virtual memory is constantly increasing and physical one looks like an irregular saw pattern. The process is quite hungry for memory and at times the OS frees it. Though, at some point memory consumption seems to get too big and something in the stack get's killed.
But the behavior above does not seem to be related to the audio export code. At least, virtual memory consumption also increases linear when running the whole
XmlTestsuite instead of the audio export and other platforms do not show this issue. Therefore, I would consider this "solved" for now.implements #2023