CMAF decrypt was the bottleneck for offline-cache gapless. Live
testing showed a 208 MB HiRes bundle took ~22 seconds to decrypt end-
to-end, which made gapless for anything longer than a 3-minute track
impossible (the gapless pre-emptive window is ~5s before track end,
so a 22s decrypt can't land in time regardless of how early we start).
Two changes, complementary:
1. `.cargo/config.toml` with `target-cpu=x86-64-v3` (Haswell baseline).
The `aes` crate ships both a software implementation and an AES-NI
hardware path, runtime-dispatched via `cpufeatures` — but the
AES-NI path is only compiled in when the appropriate target-feature
is enabled at build time. Default dev builds compile ONLY the
software path, which hits ~10 MB/s on a modern CPU. Haswell+ (2013
and up, every realistic QBZ user) supports AES-NI and clears
400 MB/s+. For prebuilt distribution binaries we'll want runtime-
dispatch via subfunction build or dynamic linking, but for self-
built and release-source-from-tag scenarios this is the right
default.
2. `decrypt_segments_into` no longer allocates a Vec per frame. Was:
frame = seg_data[..].to_vec(); // alloc
decrypt_frame(&mut frame); // in-place
output.extend_from_slice(&frame); // copy back
Now:
let start = output.len();
output.extend_from_slice(&seg_data[..]); // single copy
decrypt_frame(&mut output[start..]); // in-place
For a HiRes FLAC with ~50K frames this saves 50K small allocs +
50K double-copies. Output Vec is already pre-sized via
with_capacity(total), so no reallocation growth during extend.
Combined expected impact: 22s decrypt on a 208 MB track → under 500ms,
which fits inside the 5s gapless window with headroom to spare.
cc
vicrodh
aae685e701