I work on virtual music instrument ( uvi.net ) and we store all the samples in FLAC format because of its compression level, its lossless capability and

its decoding speed. This is clearly the best in the world and we love it. We have a streaming engine tailored to its use.

In the case of a piano library, we open around 10.000 files at loading time to read hundred of ms of it the file beginning as preload to avoid latency when the user start playing.

Then depending on what the users play, we could read around 400 files at the same time and even more in our new engine where we could up to 2000 files where we multi thread the audio rendering.

Hence even small optimization are very welcomed :)

I don't mind losing the 32bits x86 optimization are we don't have users on 32 bits Intel platform.

I wouldn't even mind paying someone for better optimization in neon for example.

Hope this clarify things.

Le 06/07/2022 à 20:36, Martijn van Beurden a écrit :
Olivier,

On a more general note, do you experience the decoding speed of libFLAC as a bottleneck in your application? Decoding speed of FLAC is already best-in-class among lossless audio codecs, so I actually wasn't expecting anyone to object to a (small) decrease in decoding speed. There have been more changes recently that could (slightly) affect decoding speed, but for good reasons. I am aware that the following changes affect decoding speed - https://github.com/xiph/flac/commit/1bec35e33757fc38261b0acfa3c032e720d2baf0 - https://github.com/xiph/flac/commit/63ac1c37bebbda5ca61ad5a05a1d8fba2883f629

Comparing current git to release 1.3.4 for my 64-bit x86 machine this adds up to about 4% slowdown for both 16-bit and 24-bit audio. When using a 32-bit compile, for 16-bit audio this cancels out against the speed gain from the removal of optimizations and for 24-bit audio this compounds to about 10% speed loss. Numbers may vary depending on the CPU specifics. I didn't think this would be a problem, but please speak up (and if possible elaborate on the details) if it is.

--
Olivier Tristan
Research & Development
www.uvi.net

_______________________________________________
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Reply via email to