HN user
github.com/PADL lukehoward.com
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.
Also it’s nice for things like SPI which have no user space non-blocking API.
Microsoft Surface Dial is nice. You'll also need to write a driver...
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.
[1] https://forums.swift.org/t/an-embedded-audio-product-built-w... (note, older prototype)
[2] https://www.linkedin.com/posts/lukehowardmusic_heres-a-long-...
Well, it started off simpler, but, yes.
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.
Right, and I suspect as things get more complicated (and you have to ship), abstractions get leaky.
There was also the Java-like syntax for ObjC but I don’t think that ever shipped.
Yup, even with a hard drive the m68k turbo slab was no speed demon. Wasn't too bad on HPPA though.
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.
Swift actually has excellent C++ interop [1] (compared to other languages, but, I guess, not good enough for Ladybird).
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.
There’s also AES70, or OCA (https://news.ycombinator.com/item?id=46934318). More popular in audio than video, something of a competitor to NMOS (although there are parts of NMOS that were very much inspired by OCA). There are open source C++, Python, JavaScript and Swift implementations as well as some commercial ones.
IOKit was designed to support CoreAudio from the start, cc gvdl.
That is a beautiful piece of industrial design.
XMOS is still keeping the Inmos dream alive, more or less!
This is also my recollection.
Small nitpick: malloc is not a system call.
And Mach 3 vs 2.5. And a 4.4BSD (well, *BSD) user land, although in fairness the original, never released NEXTSTEP 4.0 also had this.
Another approach is swift-java, which uses Swift macros and also supports Panama.
That’s sad. One of the first pieces of (serious) software I wrote was licensed by HP for bundling with it. Didn’t use HP-UX a lot but it’s a pity we’re asymptoting towards a Unix monoculture.
Sequential doesn’t mean reentrancy safe, something which has bitten me a few times in Swift concurrency.
Not really! AES67 is essentially RTP with a PTP derived media clock. Connection description uses SDP and unicast signaling uses SIP. Just like VoIP.
Also I imagine TDM was first used in telephony.
Yup, similar for audio stuff.