Same list of cputype errors
On Wed, Jul 6, 2022 at 3:30 PM Martijn van Beurden wrote:
> Op wo 6 jul. 2022 om 21:21 schreef Scott Brown :
> > Configure for just arm64 gives neon optimizations, but "make" gives a
> bunch of cputype errors:
>
> What happens if you run 'make clean all' instead of ju
Op wo 6 jul. 2022 om 21:21 schreef Scott Brown :
> Configure for just arm64 gives neon optimizations, but "make" gives a bunch
> of cputype errors:
What happens if you run 'make clean all' instead of just 'make'?
___
flac-dev mailing list
flac-dev@xiph.
Ok, so the latest being slower on both builds at level 8 than the Released
1.3.4 makes sense with recent compression improvements. Thanks. I was using
level 8 for all tests.
As for the Neon optimizations, it seems that if I configure for Universal
binary ( -arch arm64 -arch x86_64),the neon optimi
Op wo 6 jul. 2022 om 20:45 schreef Scott Brown :
> Neon optimizations : .. no
It seems for some reason NEON is not enabled by configure. Can you
provide the config.log file so I can check what goes wrong?
> But this version is even *slower* than the released 1.3.4. Running
I got the latest from git and compiled it. the output from config looks
like this:
Configuration summary :
FLAC version : 1.3.4
Host CPU : aarch64
Host Vendor : . apple
Host OS : .
Op wo 6 jul. 2022 om 20:36 schreef Martijn van Beurden :
>
> 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
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 bee
Op wo 6 jul. 2022 om 18:34 schreef Scott Brown :
> Martijn filled me in that recent changes (since the official 1.3.4 source)
> have added ARM improvements, and that if I get the most recent code, I
> should be good.
>
Huh, I have no clue why my mailing program decided replies to this
shouldn't g
Martijn filled me in that recent changes (since the official 1.3.4 source)
have added ARM improvements, and that if I get the most recent code, I
should be good.
(I can't get the most recent code to compile, but that's a different story
I suppose)
Thanks,
Scott
On Tue, Jul 5, 2022 at 2:44 PM bri