Le 07/07/2022 ? 09:34, Martijn van Beurden a ?crit?:
> Op do 7 jul. 2022 om 09:07 schreef olivier tristan <o.tristan at
uvi.net>:
> > Hence even small optimization are very welcomed :)
>
> I presume you use libFLAC directly then. Sadly there is little left to
> optimize in the decoder. Below is an excerpt of the output of gprof on
> flac decoding a track
>
> > ?% ? cumulative ? self ? ? ? ? ? ? ?self ? ? total
> > time ? seconds ? seconds ? ?calls ? s/call ? s/call ?name
> > 34.87 ? ? ?0.68 ? ? 0.68 ? 680925 ? ? 0.00 ? ? 0.00
> ?FLAC__bitreader_read_rice_signed_block
> > 25.64 ? ? ?1.18 ? ? 0.50 ?6004826 ? ? 0.00 ? ? 0.00
?FLAC__MD5Transform
> > 14.36 ? ? ?1.46 ? ? 0.28 ? ?46030 ? ? 0.00 ? ? 0.00
> ?FLAC__lpc_restore_signal
> > ?8.72 ? ? ?1.63 ? ? 0.17 ? ?23457 ? ? 0.00 ? ? 0.00 ?read_frame_
> > ?5.13 ? ? ?1.73 ? ? 0.10 ? ?23457 ? ? 0.00 ? ? 0.00 ?write_callback
> > ?3.08 ? ? ?1.79 ? ? 0.06 ? ?23457 ? ? 0.00 ? ? 0.00
?FLAC__MD5Accumulate
> > ?3.08 ? ? ?1.85 ? ? 0.06 ? ? ? ? ? ? ? ? ? ? ? ? ? ? read
> > ?2.56 ? ? ?1.90 ? ? 0.05 ? ?50901 ? ? 0.00 ? ? 0.00
> ?FLAC__crc16_update_words32
> > ?1.03 ? ? ?1.92 ? ? 0.02 ? ?23457 ? ? 0.00 ? ? 0.00
> ?write_audio_frame_to_client_
> > ?0.51 ? ? ?1.93 ? ? 0.01 ?2016520 ? ? 0.00 ? ? 0.00
> ?bitreader_read_from_client_
> > ?0.51 ? ? ?1.94 ? ? 0.01 _IO_file_seekoff
> > ?0.51 ? ? ?1.95 ? ? 0.01 write
>
> As you can see, the bitreader takes up most time. This is however not
> something that can be optimized with SIMD/vector instructions like
> SSE, AVX, NEON etc. It is also strictly a sequential process. In the
> past there have been several attempts at improving speed of this call.
> You could try for yourself configuring using ./configure
> --enable-64-bit-words or cmake -DENABLE_64_BIT_WORDS=ON whether that
> brings any (small) improvement.
>
> Next the MD5 transformation takes up a lot of time too, but I suppose
> you do not use that anyway. It is disabled by default when decoding
> using libFLAC directly.
>
> Finally the lpc restore takes up some time and can be improved with
> SSE, AVX, NEON etc., but it represents only a small part of the
> decoding CPU load.
>
>
We use libflac directly indeed so MD5 is not enabled in my case.
We indeed see in the perf analyzer
FLAC__bitreader_read_rice_signed_block and FLAC__lpc_restore_signal
> Perhaps it is possible to add a switch to the encoder to create FLAC
> files that are optimized for decoding speed instead of size. Would
> that be something you would use? For example trading in 5% less
> compression against 30% more decoding speed, assuming that MD5
> checking is already off?
This would indeed be interesting.
The material we use are very well compressed by FLAC as this is just a
single note of an instrument as opposed to a song.
For example in a piano library, we can divide the sample size by 4.
--
Olivier Tristan
Research & Development
www.uvi.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/flac-dev/attachments/20220707/3e0abeae/attachment-0001.htm>