Apple Silicon/ARM support

[gumbogal]

New and upcoming apple hardware includes ARM SoC chips instead of Intel. It would be great if Syncplay had a native build to go alongside its already great release lineup. Unfortunately I can't contribute myself (I am not a developer), this is just to bring the issue to attention.

[albertosottile]

It would be nice indeed... unfortunately, at the moment we do not have any M1 hardware available. Nevertheless, we depend on an extensive tool chain that has not been ported to Apple Silicon, yet, so we still have to wait before working on this.

In the meantime, it would be interesting to know if (and how well) the current Syncplay app bundle runs on Apple Silicon via Rosetta 2.

@yerbestpal Do you have a Mac with Apple Silicon to test that?

[gumbogal]

@yerbestpal Do you have a Mac with Apple Silicon to test that?

Yes, and I will set a remainder to test it out tomorrow afternoon.

[gumbogal]

I thought I had better write back to say that I haven't forgotten this, I've just had some trouble trying to get someone I know who uses Syncplay to spare the time to help test it out.

[gumbogal]

I tested using a very short video with two other viewers. As far as I can tell, there are no issues whatsoever. I used VLC.
These are the settings used:

[NilsIrl]

qt 6.2 now supports apple silicon which would require upgrading from PySide2 to PySide6

[albertosottile]

Finally got a new M2 MacBook Air, of course it is time to experiment with Apple Silicon and universal2 for Syncplay. At this link you can find a universal2 build of Syncplay latest master: [REDACTED, use the second build linked below]

Known issues:

• the app goes into segfault every time it is quitted.
• the bundle is 350 MB when zipped, 900 MB when installed. Not sure if there is anything we can do about this...
• the app is not signed, so it needs to be opened with Right Click + Open as usual

Please, report here if you managed to run this universal2 bundle on your Apple Silicon/Intel Macs and also if you find any other issues with it.

[albertosottile]

I managed to obtain a universal2 build from Github Actions, despite currently pending issues with setup-python (see actions/setup-python#271 and actions/runner-images#4133). The new build solves all the previously known issues (except for the missing app signature, which requires a paid Apple Developer account).

Artifacts for the new build can be downloaded from here: https://github.com/Syncplay/syncplay/actions/runs/2905232376, direct link to dmg: https://github.com/Syncplay/syncplay/suites/7924100603/artifacts/337689553

Once again, please test this on your Macs and let me know if it correctly runs as a universal2 binary or not.

[albertosottile]

@yerbestpal @cordelac @tristan-k @NilsIrl Gentle ping to ask you if you could test the universal2 build linked above with your Macs and report here any bugs you may find. Thank you all.

[ExTBH]

I installed from the direct link above
first run was fine
i got could not check for updates automatically, so i closed the app and reopned and now being greeted with this

clicking ok opens sncplay with following logs

[21:54:32] Attempting to connect to syncplay.pl:8998
[21:54:33] This client does not support TLS
[21:54:33] Successfully reached syncplay.pl (151.80.32.178)

on my Linux same room and server connects with TLSv1.3.

I got 2 errors? in my console

AggregateDictionary is not supported on this platform



OSErr AERemoveEventHandler(AEEventClass, AEEventID, AEEventHandlerUPP, Boolean)(GURL,GURL handler=0x1b18a25b0 isSys=NO) err=0/noErr

rest looks good i tried one video works fine.

Macbook Air M1, MacOS 12.6 Monterey

[albertosottile]

Thanks for reporting this. I can reproduce, and I am frankly surprised this had worked for me the first time. Perhaps I focused my testing mostly on the binary built on my system.

Basically, one of our dependencies (namely, cffi) does not provide universal2 wheels on PyPI. This essentially makes impossible to build a universal2 version of Syncplay.

I asked upstream for advice. We could also build our own universal2 wheel of cffi but, for the moment, I would avoid that.

If this issue is not solved, our only option is to ship two versions of the macOS app (Intel:x86_64 and Apple:arm64).

[ExTBH]

i don't use my mac for content watching, so my comment should not be taken into account, but having a dedicated binary for my arch looks better, you get smaller size and less bloat it only have what you need :)

[albertosottile]

That would be indeed preferable for many reasons but, unfortunately GitHub Actions does not support the arm64 architecture (see actions/runner-images#2187), and so this is also not possible for us at the moment. Therefore, currently our only option to ship native arm64 code is building a universal2 app on x86_64, which is what I tried to do up to now.