Silent failure on Apple Silicon
maxall41 opened this issue · 13 comments
Rubato seems to silently fail when used on Apple Silicon. I have tested this with all of the examples and they just seem to silently fail on my M2 mac. But work fine on an x86 based linux VM on AWS with the exact same configuration. I also don't get any logs with the log feature when this happens.
I have been using it quite a bit on my M1 Mac and haven't noticed any troubles. Can you give a simple example that triggers the problem?
I just tried a few of the examples on my M1 Air. All ran without trouble. I tried both from the master branch and the upcoming version in next-0.13. I use rustc v1.67.0.
Im using the fftfixedin64 which does not fail silently but throws an error:
Opening files: africa.wav, test.wav
Resampling from 22050 to 44100
Copy input file to buffer
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Imaginary part of first value was non-zero.', /Users/maxall4/Downloads/rubato/src/synchro.rs:180:14
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
But the async resamplers just fail silently. I ran this with this file: https://www.ee.columbia.edu/~dpwe/sounds/music/africa-toto.wav with this command:
cargo run --example fftfixedin64 africa.wav test.wav 22050 44100 2
Did you first convert the wav to raw samples? The examples don't include any parsing of wav file headers and are only able to process raw data in 32 or 64 bit float format.
Yeah I removed the header with sox before running the command. You can also see a real world example of this issue on the songbird next branch with this example: https://github.com/serenity-rs/songbird/blob/next/examples/serenity/voice/src/main.rs
Ok then please provide the exact command you used convert the file with sox.
Sure that would be:
sox africa.wav africa.raw
That command just strips the header off, it doesn't do any sample format conversion. The resulting file is still 16 bit integers. The ...64 examples assume the input is 64-bit floating point. It will read four consecutive 16-bit samples as a single 64-bit floating point number, with unpredictable results.
Try again with this sox command:
sox africa-toto.wav -e floating-point -b 64 africa_f64.raw
The resulting file should be 4x larger than the original.
That works so I think this issue may be more of an issue with songbirds implementation of rubato than an issue with rubato itself.
Actually sorry. I just checked and that doesn't work. It makes a file but it is mangled and unplayable. I could see how this could result in a silent error inside of songbird.
The output file is also 64-bit floats. Convert it back to a 16-bit wav:
sox -e floating-point -b 64 -r 44100 -c 2 test.raw -e signed-integer -b 16 africa_resampled.wav
OK that does seem to work. Then it probably is an issue with songbirds implementation.
Closing since things are working as intended.