You might want to make the port index instead a bit mask, that will let you support multicast and also selective broadcast flooding (although if you have limited space you’ll likely make broadcast flooding the default).
I haven't used it, but there's also Avocado OS [1]. Myself, I use Yocto for our embedded build. It's not perfect but for our application, which involves building a bunch of software that uses both Swift and Flutter for an embedded audio product running on a RPi CM4, it works just fine. Shout out to Mender for A/B updates.
Well, also to be clear, I did find a great hardware engineer to design the board based on my somewhat outrageously over-engineered specifications. And I have been working on it for three years and haven't shipped.
It's a great question, and indeed a centralised mixer is pretty much the common approach as it allows for economies of scale. I guess there's a philosophical bent, the same reason I run my own SMTP and IMAP servers instead of Gmail: I like distributed systems. The practical bent is that, in my studio (the target market!), I only really need one or two of these, so the economy of scale doesn't apply. And interestingly with things like Lawo .edge we are seeing distributed mixers come into fashion.
And as you point out, being protocol-agnostic means that it can fit into a lot of scenarios, which might be useful (say) if it were to be a hire product.
Feel free to drop me a line if you want to chat more, I'm lukeh at padl dot com.
Re: yours, that is a _long_ boot time. Boot time on mine isn't great, but I think I'm just going to have to accept that as an artefact of U-Boot, Linux, and an Ethernet switch chip that takes some time to initialise.
Anyway, re: my widget: it's a personal monitor mixer [1], something one might use in the studio or live, not dissimilar to existing products in the market, except: it supports up to 64 channels of Dante or AVB natively, it has a super nice (HiDPI) UI, and absolutely everything is remote controllable using OCA (AES70) or OSC. I even have a MCP bridge so you can let Claude manage it ;) [2]
The hardware is a custom board that hosts a CM4 SOM (for the control plane and UI), a Brooklyn 3 SOM (Dante), and an XMOS which runs the mixer firmware and AVB stack. There are also some nice AKM DACs, and a Marvell Ethernet switch chip that connects the SOMs and XMOS to two external Ethernet ports.
The CM4 runs Yocto which manages the switch in DSA mode (i.e. hardware offloaded bridge), runs the gPTP and SRP stacks for AVB, the OCA daemon, and the UI (which is just a regular OCA client). SSH is presently enabled but there's not a lot to do once you're in there. Working on secure boot at the moment with U-Boot and dm-verity.
I’m building an audio device. It runs Linux for the control plane (it’s just a CM4 running Yocto, maybe I’ll leave SSH running on production units, maybe not, haven’t decided yet). No audio passes through the CM4, there’s a dedicated FPGA and MCU for that. It’s been a fun project, first time hardware for me, feel free to ask my anything!
SIP is anti-feature for a certain class of users, but the right tradeoff for most consumers. At least you can disable it. And even as a developer I leave it enabled.
Still rocking a 2019 (Intel) Mac Pro here, all slots filled with various Pro Tools and UAD DSP cards, SSD, GPU, etc. I'm planning to get as much mileage out of it as I can. I'm sure a Studio would be more performant, but the Thunderbolt to PCIe chassis are not cheap.
I hear you. Actually I read this thread because we’re using jemalloc in an embedded product. The only way I found to work on interesting problems here was to work for myself. (Having said that I think Apple might have some security research in Canberra? Years ago there was LinuxCare there and a lot of smart people. But that was in 2003…)
To some degree. There are _many_ SwiftUI clones that support other frameworks such as Gtk and Windows, with varying states of maturity. Or you can share the business logic and write the UI natively in Swift.
It does like to weasel in if you let it write a commit message, and even after rewriting and force pushing, it seems to hang around on the GitHub contributor list.
Also things like support for GSS-API pre-authentication mechanisms (so, you can use an arbitrary security mechanism such as EAP to authenticate yourself to the KDC), the new SAnon mechanism, pulling in some changes from Apple's fork, replacing builtin crypto with OpenSSL, etc. Lack of release has been typical OSS lack of resources: no one is paid to work on Heimdal full time.
You also need synchronization to mix sources (common in any production) without incurring the latency and resampling of asynchronous sample rate conversion.