Feature request: Support Apple Silicon M1 on macOS

[Patronics]

Is your feature request related to a problem? Please describe.
It's been over a year since Apple released their M1 Macs, and since then they've released the M1 Pro and Max, which are very powerful for running tensorflow, but there's still no support for them implemented for Coqui.

Describe the solution you'd like
Port Coqui to support running on Apple's M1 Series chips, and/or document the steps to build it manually.

Describe alternatives you've considered
Running Deepspeech in x64 emulation mode with Rosetta doesn't seem to work, and Coqui hasn't added any commits to add support for Apple Silicon.

Additional context
There's some previous discussion about it here and a list of issues here that would seem to mostly have been since resolved, such as tensor flow support.

[reuben]

Does GitHub Actions support building Apple Silicon binaries? If so it should be relatively easy to get it up and running. No one in the team has the hardware so until that changes or someone donates a machine it'll be up to the community to provide not just answers but also pull requests.

[wasertech]

I have the following concerns about this.

1. Why would someone train on a laptop?
2. Isn't CUDA only available on Nvidia GPUs?
3. Given the thermal related issues of those chips, is it really a good idea?

[reuben]

This issue is about the STT inference package, or at least I've been operating under that assumption 😅. Training on M1 is out of scope for our project for the reasons you mentioned.

[wasertech]

I was under the wrong assumption then. Thanks Rüben.

[reuben]

Looks like both libstt.so and the Python package build from source just fine, just need to figure out if we need any massaging of platform names to make things compatible, as the wheel gets created with the macosx_12_0_arm64 tag. I also notice that our Python 3.10 package got magically upgraded to a macosx_10_10_universal2 tag, but it doesn't work because the libstt.so embedded in it is not a universal binary:

$ pyenv install 3.10.2
python-build: use openssl@1.1 from homebrew
python-build: use readline from homebrew
Downloading Python-3.10.2.tar.xz...
-> https://www.python.org/ftp/python/3.10.2/Python-3.10.2.tar.xz
Installing Python-3.10.2...
python-build: use readline from homebrew
python-build: use zlib from xcode sdk
Installed Python-3.10.2 to /Users/reuben/.pyenv/versions/3.10.2

$ pyenv virtualenv 3.10.2 test-stt
$ pyenv local test-stt
(test-stt)  $ pip install stt
Collecting stt
  Downloading stt-1.2.0-cp310-cp310-macosx_10_10_universal2.whl (3.1 MB)
     |████████████████████████████████| 3.1 MB 306 kB/s
Collecting numpy>=1.21.4
  Downloading numpy-1.22.2-cp310-cp310-macosx_11_0_arm64.whl (12.8 MB)
     |████████████████████████████████| 12.8 MB 142 kB/s
Installing collected packages: numpy, stt
Successfully installed numpy-1.22.2 stt-1.2.0
(test-stt)  $ stt --model ~/Downloads/coqui-stt-1.1.0-english.tflite --scorer ~/Downloads/huge-vocabulary.scorer --audio ~/Development/STT/data/smoke_test/LDC93S1_pcms16le_1_16000.wav
Traceback (most recent call last):
  File "/Users/reuben/.pyenv/versions/test-stt/bin/stt", line 5, in <module>
    from stt.client import main
  File "/Users/reuben/.pyenv/versions/3.10.2/envs/test-stt/lib/python3.10/site-packages/stt/__init__.py", line 23, in <module>
    from stt.impl import Version as version
  File "/Users/reuben/.pyenv/versions/3.10.2/envs/test-stt/lib/python3.10/site-packages/stt/impl.py", line 13, in <module>
    from . import _impl
ImportError: dlopen(/Users/reuben/.pyenv/versions/3.10.2/envs/test-stt/lib/python3.10/site-packages/stt/_impl.cpython-310-darwin.so, 0x0002): tried: '/Users/reuben/.pyenv/versions/3.10.2/envs/test-stt/lib/python3.10/site-packages/stt/_impl.cpython-310-darwin.so' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e')), '/usr/local/lib/_impl.cpython-310-darwin.so' (no such file), '/usr/lib/_impl.cpython-310-darwin.so' (no such file)

So I guess building a universal libstt.so would automatically give us Apple Silicon support on 3.10.

[reuben]

Cross building from an Intel mac with bazel build --config=macos_arm64 also seems to work fine, so we can handle that in CI. It seems newer bazel will automatically generate universal binaries if supported but TensorFlow 2.8 is not using that version yet, but maybe it works out of the box.

[reuben]

I think I misunderstood the notes, it's only about toolchain binaries. Plus the build is broken on bazel 5.0.0. I guess the easiest way is to do two separate builds, one for x86_64 and one for arm64, and then manually collect the artifacts and call lipo to create the universal binary.

[wasertech]

So you have the machine now 😂👍🏻

[reuben]

Looks like choosing macos-min-version is not enough to select the appropriate version of the SDK on the macos-10.15 workers, need to figure out how to force it. Once that's working, we need to install arm64 version of dependencies linked against, maybe like this: Homebrew/discussions#2843 (reply in thread)

[reuben]

Aha, bazel ignores xcode-select, you have to pass e.g. --xcode_version 12.2 to specify which Xcode version you want to use when multiple are installed.

[reuben]

PR #2100 is building and passing tests, we now have universal builds for libstt.so, libkenlm.so and the stt CLI client. The bindings need a bit more work: the SWIG bindings also need to be made universal, and for Node/Electron node-pre-gyp needs to be updated and made to handle the new architecture.

[reuben]

Also the stt binary for arm64 is built without SoX enabled, because we need to find a way to install the arm64 version of SoX and its dependencies on an x86_64 macOS worker in CI, to link against them. Some tips were shared here but I still haven't been able to try them out: Homebrew/discussions#2843 (reply in thread)

[Vrajs16]

Any progress made with this? I really want to use coqui stt for a project. I tried to follow the guide for building a binary but didn't work out on m1 macbook. If anyone could help me generate the binary on my m1 macbook that would be greatly appreciated as the docs didn't have anything about compiling on an m1 machine. Thank you.

I tried emulating with x86_64 either got bad instruction set or if I run it with arm it says mach o file arm64e needed.