Henrik Enquist

IMO the conversions int float are all weird! https://github.com/RustAudio/cpal/blob/master/src/samples_formats.rs#L81 In order to reach a max value of +1.0 instead of 0.999..., positive and negative values are treated differently. This give...

I had similar issue with a crate for windows, where I simply worked around the problem by hosting the docs on GitHub pages instead. See https://henquist.github.io/wasapi-rs/ The docs are built...

I'm looking forward to having this merged! Just one comment: I get the impression that i32 is done, while i24 needs more work. If that is correct, then I think...

Sure! It doesn't say that much unfortunately. ``` pi@raspberrypi:~ $ /mount/ssd/rustc/bin/rustc --version --verbose rustc 1.57.0-dev binary: rustc commit-hash: unknown commit-date: unknown host: aarch64-unknown-linux-gnu release: 1.57.0-dev LLVM version: 13.0.0 ```

It doesn't seem to matter much what my benches contain, it fails no matter what. I just started building rustc from today, will try it as soon as it's ready...

I need a newer stdarch than in the latest nightly, with all the vld* and vst* intrinsics.

The updated llvm unfortunately made no difference. If I go back to the RustFFT version just before I started using the vld* and vst* intrinsics builds and benches fine. I'll...

The crash seems to come when I compile a benchmark if my FFTs use this function: https://github.com/HEnquist/RustFFT/blob/vldx/src/neon/neon_vector.rs#L156 It only fails with `cargo bench`, with `cargo test` it's all good.

Using the `vld2q_f64_fake` instead of `vld2q_f64` makes the benches build and run fine!

By the way, `vld3q_f64` and `vld4q_f64` cause no problems. No need for fake-versions of those to make the benches ok.