Add macos-version-min flag

[morajabi]

trafficstars

Fixes #30

Let's start here, let me know what should I fix/make better. This is my first time messing with Rust custom build script and cc :)

[bschwind]

Thanks for the PR! If you could add build/test instructions, I can run this on the machines I have:

• Intel Macbook Pro 2014 - Big Sur 11.6.2
• M1 Mac Mini - Big Sur 11.7.0
• M1 Macbook Pro - Monterey 12.6.0

[morajabi]

So I'm using webrtc-audio-processing crate in a Rust macOS application built with Tauri.

This is a build from the branch master of this repo. This should crash on startup with the error below:

• DMG for x86_64: Noor_0.0.38_x64.dmg.zip The error:

So after this patch, I no longer the error and app loads normally to its login screen. The correct build:

• DMG for x86_64 using the patched webrtc-audio-processing: Noor_0.0.41_x64.dmg.zip

I can make a minimum failing case later in a public repo, but I'm a bit busy atm. I can also show you the code in private. Basically, all you need to do is to load the webrtc-audio-processing crate in the main.rs of a bare minimum tauri app and build for macOS. It's one command: npm tauri build --target x86_64-apple-darwin.

[morajabi]

Alright, I made a minimal failing example here: https://github.com/morajabi/wap-example

[bschwind]

Thanks for the example, @morajabi

So just to be clear, to test this properly I should build wap-example on an M1 Machine with npm tauri build --target x86_64-apple-darwin, and then try to run that built application on an intel machine?

[morajabi]

My pleasure @bschwind

That is correct. I suggest building (running the build command) on this machine of yours:

• M1 Macbook Pro - Monterey 12.6.0

And trying to run the binary on this one:

• Intel Macbook Pro 2014 - Big Sur 11.6.2

It should crash using the master branch of webrtc-audio-processing. If this was the case, change the dependency in the Cargo.toml:

[dependencies.webrtc-audio-processing]
git = "https://github.com/there-so/webrtc-audio-processing"
branch = "fix/missing-symbol"
features = ["bundled"]

Run

cargo update

Now build again and transfer to the Intel Big Sur machine. This one should run without an issue and show a window.

FWIW: You can build using --target universal-apple-darwin target to be able to see on both machines from a single build.

P.S. Yesterday I read your custom keyboard post on Reddit, it was so cool :)

[bschwind]

Hmmm, this is a bit mysterious. With no modifications to your example repo, I was able to build with:

yarn tauri build --target x86_64-apple-darwin

(various invocations of npm was giving me issues so I tried yarn and it worked)

I built on the M1 Pro machine, received a wap-example.app file, transferred it to the Intel machine, and it was able to run just fine. I suspect maybe the compiler stripped the webrtc code out completely.

I added some code to print some stats so that the code isn't stripped:

fn main() {
    let config = InitializationConfig {
        num_capture_channels: 0,
        ..InitializationConfig::default()
    };
    let p = Processor::new(&config).unwrap();
    dbg!(p.get_stats());
    tauri::Builder::default()
        .invoke_handler(tauri::generate_handler![greet])
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

And now the app doesn't open on the Intel mac.

However, I update the dependency as you said but it still has the same behavior of not opening on the intel machine.

Actually, with the modifications of preventing the compiler from stripping the webrtc code, I can no longer open it on the M1 machine either (which should have no problem running it through Rosetta I believe)

Not sure if I'm doing something wrong but I think I'm not getting the same behavior as you.

P.S. Yesterday I read your custom keyboard post on Reddit, it was so cool :)

Awww thanks! I'm working on making a better version of it, with support for different case styles. Hoping to get that out soon :)

Edit - Oh you know what, I think my code change introduced a panic before the tauri app can even run, let me retry that.

[bschwind]

So I fixed the code to use at least one capture channel instead of 0 (which did indeed cause a panic), but I'm back to the point where I can build the app with the main branch of this repo, or your fork, and both work on the Intel mac.

Is it possible I'm just on a new enough version where it doesn't exhibit the behavior you were seeing?

[morajabi]

@bschwind Did you make sure to do cargo update and check the Cargo.lock to make sure it has picked up the new branch? Cause in my case a simple cargo build (tauri build) never updated the branch in Cargo.lock thus the build was using whatever it was using before changing your Cargo.toml.

what you described seemed like you were getting mixed results due to Cargo not using what you specify in the Cargo.toml and instead picking up the commit hash it has cashed in its lock file.

[bschwind]

I did run cargo update in between builds after changing the dependency but I'll try it again tomorrow morning and report back.

[bschwind]

Okay, I ran cargo clean and cargo update just to be sure, and was very careful to check Cargo.lock to see that I'm using the master branch of tonarino/webrtc-audio-processing.

I build it on the M1 Pro machine, but I'm still able to run it on the Intel machine.

However I did download your example DMG (risky move from a security standpoint :P) and saw that it crashes as expected.

But with your minimally viable wap-example, you were able to reproduce the crash, right?

Maybe my Intel machine is just on a newer version of MacOS that doesn't have the issue?

In any case, I'll review the code and trust that it fixes the issue you're facing, as it doesn't seem to introduce any issues for builds on the various machines I have.

[morajabi]

Now I think it comes down to our difference in our M1 machine's macOS version. I've built on Ventura, but you're building on Monterey. I suspect Ventura uses a newer libc++ or something by default, so it isn't compatible with macOS Big Sur. If you want, we can do a quick screen-share over Zoom and I build a version using the wap-example repo and send to you so you see me doing the build (to eliminate the security risk for you).

[bschwind]

I've built on Ventura, but you're building on Monterey

Ahhh, that's probably it. I don't think a call is necessary though, if you've witnessed this change fixing it for you I think we can go ahead and merge it. I was just trying to recreate the issue if I could, but the change itself seems plenty low risk that I'm okay with it as-is.

[morajabi]

Yes, it does indeed fix it for me. I will keep monitoring as well, you can wait a bit longer until our alpha launch in a couple of days and we can try more widely.

[bschwind]

you can wait a bit longer until our alpha launch in a couple of days

Ooh exciting! I'd be interested to hear if your users run into any issues with the library, that's certainly a good way to test various platforms :)

I might wait a bit longer too and see if I can reproduce it with a different machine - @skywhale are you on MacOS Ventura?

Or maybe I'll update to Ventura, but I can't currently tell if it's an upgrade or downgrade in experience.

[bschwind]

@morajabi how has the launch gone so far?

[morajabi]

@bschwind Intel users did not report any crash so far!