I haven't experimented with lowering these numbers in maybe two years, but I use BlackHole to route 8 channels from Traktor to Ableton Live (all four decks in stereo as external outputs). I have one big aggregate device with my internal speakers for clock, the BlackHole bridge, and an original RME Babyface for the physical output.
Looks like I have Traktor set to 192 samples @ 44khz. It's showing "4.4 ms processing + 17.6ms output = 22.0 ms" in its UI.
Ableton is set to 128 samples, and showing "Input Latency 4.72 ms, Output Latency 6.05 ms, Overall Latency 10.8 ms".
So maybe 33.8 ms in the whole pipeline? Although I throw audio signal across the room via the Babyface's optical out to a cheap optical -> RCA box, so that's probably adding a little more to my physical environment.
I've had this same Traktor/Live setup going for a long, long time. At one point I even used a physical loopback with the Babyface's optical out/in carrying 8 channels between Traktor and Ableton. That was sadly better than any software available before BlackHole. It was solid, although a bit higher latency, and it's nice to be able to use the optical out for its intended purpose!
I used to get very occasional crackle this BlackHole setup, until I tried a random tip of using the built-in speakers as the clock source on an aggregate device. It's been rock solid since. I could probably lower sample buffers even further these days (M3 Max)...
I use Loopback and BlackHole both, although for different reasons/setups. I guess it's more an artifact of the surrounding macOS environment at the conception of each project. BlackHole's first commit was September 2019, while Loopback was released in 2016 (but also shares its capture engine with Audio Hijack, and its 1.0 release was 2002!)
I'm in game development, and I run ESXi for two reasons:
* Unmodified macOS guest VMs can run under ESXi (if you're reading this on macOS, you have an Apple-made VMXNet3 network adapter driver on your system--see /System/Library/Extensions/IONetworkingFamily.kext/Contents/PlugIns/AppleVmxnet3Ethernet.kext )
* Accelerated 3D has reasonable guest support, even as pure software. You wouldn't want to work in one of those guest VMs, but for any sort of build agent it should be fine, including opening i.e. Unity editor itself in-VM to diagnose something
Does anyone know where either of these things stand with Proxmox today?
I imagine macOS VM under Proxmox is basically a hackintosh with i.e. OpenCore as bootloader?
I run macOS/OSX Sonoma in Proxmox. It does pcie/gpu passthrough (AMD rx580 8gb). The proxmox host is running a AMD Ryzen 7 5700G cpu and has 64gb memory. The mac vm disks are on a zfs fs on a wd black nvme ssd.
It's the fastest mac I've ever owned and it's virtual, executed on a machine running a chip that apple never supported, and you'd never be able to tell it was a vm unless you were told so. kvm and vfio are amazing pieces of software.
Why? IIRC running ZFS on NVMe SSDs limit their performance seriously. With sufficient queue depth modern SSDs can easily get up to 1mln+ IOPS and on ZFS I can barely get 100k :(
Most probably because ZFS still has the most extensive data correctness guarantess of all filesystems on Linux. Yes, bcachefs will have checksums too but it it is still in beta.
copy on write, instant snapshots, data checksumming, easy rollbacks, auto trim, compression
proxmox takes advantage of zfs' features if available, like when you select block storage on zfs it makes each vm disk its own dataset which you can tune as you see fit for each one. cloning a vm is instant if you make a cow clone. suspending the vm to do snapshot based backups is also nearly instant, etc
Disable atimes and turn off the arc cache and metadata cache (don't really need either with fast storage compared to spinning rust) and use lz4 compression and you minimize write amplification or needless wear on the drive. zfs is perfectly fine on ssd for my use case
The lack of 3D paravirtual devices is a real sore spot in kvm. To my knowledge, virgl still isn't quite there but is all there is so far in this space. VMware has the best implementation IMO and everything else is a step down.
Running macOS is only supported/licensing-compliant on Apple-branded hardware anyway, and with the supported Intel Macs getting pretty old this was inevitable anyway.
If you’re just running a bare metal hypervisor then you may as well just go for a second hand tiny form factor platform. No point paying 15-20% extra for the same specs in a svelte case if you’re not running native macOS.
> No point paying 15-20% extra for the same specs in a svelte case if you’re not running native macOS.
The main point is proper non-hackintosh support for running (unlimited amount) of macOS vms on esxi - which requires Apple hardware. Running macOS, Windows and Linux on the metal is another benefit. IMO it's almost as versatile as a framework chromebook (chromeos, crostini, kvm, android with play store)
The SPICE backend has decent OpenGL 3D support with software rendering, it's slow but it works for simple graphics. It's intended for 2D so the desktop's pretty fast IMO. That only works for Linux and Windows guests though, not Apple ones.
MacOS VMs do work in Proxmox with a Hackintosh setup but you pretty much have to passthrough a GPU to the VM if you're using the GUI. Otherwise you're stuck with the Apple VNC remote desktop and that's unbearably slow.
For paravirtualized hardware rendering you can use virtio-gpu. In addition to Linux, a Windows guest driver is available but it's highly experimental still and not very easy to get working.
What's the best solution for remote viewing with virtio-gpu? I vaguely recall that it had some incompatibility with spice.
I have a bunch of qemu/kvm virtual machines for various tasks. For two of them I decided that graphics performance needed to be at least OK and ended up buying and passing through old Quadro cards. It'd be lovely to not have to do that.
I haven't really bothered with macos GPU acceleration, It is possible but a little fiddly with an nvidia card. I mostly rely on screen sharing to display the remote vm and that's really good (rich text copy/paste, drag and drop files, etc)
As to general guest 3d, you can do this with GPU passthrough, and although it's technical the first time, each vm is then easy.
basically I add this line to each VM for my graphics card:
hostpci0: 01:00,pcie=1,x-vga=1
and this passthroughs a USB controller for my USB dac:
hostpci1: 03:00,pcie=1
(this is specific to my system device tree, it will usually be different for each specific machine)
The passthough has worked wonderfully for Windows, ubuntu and arch linux guests, giving a full accelerated desktop, and smooth gaming with non-choppy sound.
two things I wish proxmox did better:
- passthrough USB into containers
usb is pretty fiddly to propagate into a container. It is marginally better with VMs but sometimes devices still don't show up.
- docker/podmain containers
proxmox has lxc containers, but using them is a little like being a sysadmin. Docker/podmain containers that you can build from a dockerfile would be a much better experience.
Nested virtualization also works great on ESXi for macOS guests ( so you can run docker desktop if so inclined ). I believe this is possible with proxmox as well with CPU=host but have not tried it.
Apple has been adding a lot of virt and SPICE things IIRC. Some of it isn't supported in VMware (it lacks a bunch of standard virt support), but the facilities are growing instead of shrinking which is a good sign.
On Proxmox you can do the same. You're going to need OpenCore if you're not on a Mac indeed. But if you're not on a Mac you're breaking the EULA anyway.
Mostly used it when trying to track down reported macOS bugs for an OSS project, so maybe once every few months. But it's worked quite well at those times. :)
quickemu also does the job, not just for macOS but many operating systems
"Quickly create and run highly optimised desktop virtual machines for Linux, macOS and Windows; with just two commands. You decide what operating system you want to run and Quickemu will figure out the best way to do it for you."
https://github.com/quickemu-project/quickemu
> I wouldn't personally bother with an AMS until down the line when you're sure you need it.
If the parent comment plans to print a lot of large parts, AMS will be useful. You can load multiple spools of the same filament, and a Bambu printer will switch spools when it runs out and continue printing without any intervention needed...
I was iffy about whether I really 'needed' the AMS or not when I bought my X1C.
It has since proved its worth many times over, and the auto-refill is as much the reason as multiple colors/support filaments. I'm only holding off getting a second because I want to wait for a larger-format bed printer first.
Doesn't really help the argument that it is a proprietary Google technology. The fact that it had to be "made available" to Apple means that it isn't an open standard and requires trusting Google, which many of us don't.
Encrypted RCS should be a standard. When it is Google should adopt the standard, not its proprietary version. In the meantime I want Apple to implement standards, not proprietary Google technologies.
If Google's strategy was anything other than "get Apple to adopt, then screw them", Google would have contributed the enhancements back to the standard.
Yeah - as we’re off grid with a well managed storage system we essentially have no limit on power, usually a surplus, so lighting (all LED, of course) is just negligible - if I turn every single light in the place on we barely draw 250W. For energy saving, I do have it do stuff like turn off the underfloor heating/AC when we go out, or when we are for whatever reason low on power.
Now, if they were incandescent it would be a different story entirely - it would be more like 3kW!
I do actually have one small lighting project in mind - it’s about 500 meters from our house to the mill/guest house, and I’m toying with the idea of having little LoRa/solar fairy lights that turn on and off as you walk from one to the other at night, based on device presence, zone by zone, mostly because it would feel magical.
AFAIK a big benefit of Zigbee is that it's designed to be low-power. I have motion sensors that last for 2-3 years on a coin battery, depending on location/traffic. Mains-powered devices like lightbulbs act as repeaters in a Zigbee network, so placement can be anywhere.
Looks like I have Traktor set to 192 samples @ 44khz. It's showing "4.4 ms processing + 17.6ms output = 22.0 ms" in its UI.
Ableton is set to 128 samples, and showing "Input Latency 4.72 ms, Output Latency 6.05 ms, Overall Latency 10.8 ms".
So maybe 33.8 ms in the whole pipeline? Although I throw audio signal across the room via the Babyface's optical out to a cheap optical -> RCA box, so that's probably adding a little more to my physical environment.
I've had this same Traktor/Live setup going for a long, long time. At one point I even used a physical loopback with the Babyface's optical out/in carrying 8 channels between Traktor and Ableton. That was sadly better than any software available before BlackHole. It was solid, although a bit higher latency, and it's nice to be able to use the optical out for its intended purpose!
I used to get very occasional crackle this BlackHole setup, until I tried a random tip of using the built-in speakers as the clock source on an aggregate device. It's been rock solid since. I could probably lower sample buffers even further these days (M3 Max)...