flac dev - Jul 2022 - About SSE intrinsincs in decoder

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/flac-dev/attachments/20220706/d769e79a/attachment.htm>

Op wo 6 jul. 2022 om 20:36 schreef Martijn van Beurden <mvanb1 at
gmail.com>:
>
> I am aware that the following changes affect decoding speed
> -
https://github.com/xiph/flac/commit/1bec35e33757fc38261b0acfa3c032e720d2baf0
> -
https://github.com/xiph/flac/commit/63ac1c37bebbda5ca61ad5a05a1d8fba2883f629
>
Sorry, small mistake in the last email, commits are
- https://github.com/xiph/flac/commit/1bec35e33757fc38261b0acfa3c032e720d2baf0
- https://github.com/xiph/flac/commit/1793632ee6988deb933ff7551fee92134622b558

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