I have Mycroft running on Pi3B with 64 bit OS. Due to the type of processing that Mycroft does I figured that the 64bit implementation would be faster and more responsive. Now I just need to power it down and mount it with the google AIY kit parts in my Adabot robot head. Looks like it will run great.
FYI, the Pi running 64bit OS benchmarks much stronger with sysbench vs the 32bit OS.
I’m actually using my own Distro that I’ve developed over quite a series of years. I started it just before the 64 bit x86_64 transition was common. The cool thing about having my own distro is that I can implement changes immediately. For example all of my systems are running Python 3.7.2 and kernel 4.20.
I have another box that I tested the AIY kit with, based off the stock images. That one works fine. I’m pretty sure that I won’t have any major hurdles getting the AIY bits working on the 64bit OS.
If I was to recommend a common distro to go with it would be Arch. Arch is philosophically very close to my distro.
For now though, I’d be a little hesitant to use something other than a widely-supported Raspberry Pi distro as the base for Picroft - as it is we struggle to try and support all the different audio combinations that can be used with Picroft - implementing a more niche type of OS might generate additional support load.
I have mycroft speaking and responding to requests from the command line. From what I see the google voice hat overlay is working properly (kernel 4.14.91). The google voice hat overlay doesn’t work properly with kernel 4.19 and 4.20 yet, which really isn’t an important issue at this point. The audio devices should work as well on 64bit as 32bit. Real-world testing is the only way to know for sure.
My sticking point at this time is that the PortAudio lib is throwing an error, which is preventing the mic from working. Not sure if that is 64 bit specific or not. I’m not too excited on the dependency on PortAudio that comes with pyaudio. In this case you end up going pyaudio->portaudio->alsa->pulseaudio, which seems like an unnecessarily long path to capture audio. I may look at replacing pyaudio with a direct path to pulseaudio, rather than trying to debug the PortAudio problem.
I can’t really test that easily…I use f2fs which is superior on flash due to the way that it distributes writes. This makes the flash hold up better. I started using f2fs way back when it first came out and it’s been good to me.
Better sd cards have the most impact on performance on these sbc’s. Most recently I’ve started to use 64G Samsung Evo Plus in the gray packaging (the white packaging was slower). Previously I was quite happy with SanDisk Ultra.
I should add that all of the current filesystems use 64bits to store sector locations. So that would imply that they should all operate a bit faster on 64bit archs vs 32bit. I just don’t know that it would be noticeable in real-world scenarios.
I suspect getting the 64bit libraries working with Mycroft is a separate skill set from adapting the python, but I have not seen any mention of this development on the forum, and I wanted to make someone with more than “Hello World” python skills aware of the possibility.
I’ve been interested in OpenCL in general for quite a while. It’s been underutilized even on those platforms that support it, i.e. Linux/AMD. One of the applications that I had hoped would eventually be open-sourced was an OpenCL HEVC encoder. That hasn’t happened yet as far as I know.
I’ll play around a bit with the code.
Just today I got the RasPi userspace programs to build cleanly on 64bit. vcgencmd seems to be working. My first goal with the 64bit userspace is to get the raspicam working with hardware jpeg encode (mjpgstreamer). Once I have that working I’ll be able to migrate my OctoPrint devices from 32 to 64 bits.