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!
This particular box also has RS-232, ssh (with almost zero auth), and telnet as a control plane, by default. Any of that only gets used to tweak/report various things with a rather basic human-readiable protocol. (It has built-in functions to make it more secure; I just don't care on my home LAN, or on my pop-up LANs in the field. A sane person with a professional role would have it locked down and on its own VLAN/VPN, but for me and prototyping: Telnet is actually pretty good.)
I designed none of it. I just bought it, and make good use of it. New, it was a mid-4-digit box; used, they're not so bad. (And I use it every day and like it quite a lot, hence the reluctance to go harder on the potential root shell hack.)
My box, as it sits, just does general-purpose GUI-connected DSP stuff with near-realtime tweaking. I'm in the process of getting it to grok OSC, and thus Reaper or whatever, so it has a better control surface for live work.
It has a USB interface that my Linux box treats as a sound card, which works well. My main reason for wanting to get root is to examine (solve?) its ~5-minute boot times.
5 minutes in a live sound environment is the difference between having a large, active, and involved crowd, and having everyone get bored and find something else to do.
Anyway, the FPGAs here just exist to behave as DSPs and...well, digitally process [audio] signals. It works well; I really just wish it booted faster.
And that may be its downfall. :P
---
But enough about that.
What's your device do? What are your plans and dreams with it? (Do I want one?)
I've built a very small amount of hardware. At least at the level of custom PCBs and some code, it's been richly rewarding even when I screw it up, and it makes me feel like I'm on top of the world when I get it right.
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 astounded to hear that you consider this your first hardware project. That is, to be clear, rather fucking amazing.
At first, I wanted to ask why all that work is done locally instead of just controlling a mixer over the network. Because, I mean, when networked audio is already happening there's almost invariably some kind of mixer involved somewhere, but think I get it: Controls for mixers are all over the place, but AVB and Dante are fixed and unitized and it's easy-enough to find those streams (and/or for someone to make them available) on a network.
That makes your method very universal in application. Even when the monitor feed is an analog split (as is still often the case), it's easy-enough to convert that to Dante or AVB with a stage box [which can be rented] so the performers still control their own ears.
Nice, dude.
And yes, I want one. (Whether I can afford one or not is a different thing entirely, but the want is resolute.)
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.
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.
It's really easy to fail to see this in the heat of things.
macOS has a feature where it puts an orange dot on the top right corner of your screen whenever your microphone is recording. That orange dot is normally part of the menu bar, and completely unobtrusive, but will still show up on top of full-screen windows (e.g. it'll show up on top of games if you're on Discord talking to friends), which is distracting as hell.
As horrendously annoying that little dot is, what's the alternative? Either you have an uncircumventable marker saying you're being recorded, or you don't. Any way to turn that thing off that doesn't involve disabling SIP would be trivial to exploit by anybody who managed to plant malicious recording software in the first place.
More annoying is when you use something like SoundSource (a paid app which adds per-app volume control and input/output redirection to macOS... a feature that by all rights should be built in in any reasonable OS) you get a permanent purple dot indicating a third party tool is intercepting audio.
Again, I get it, but as a power user this kind of stuff is just infuriating.
It's also annoying that macOS doesn't already have at least basic per-app volume mixing.
So much pain in macOS is in areas like this, trying to hack basic features back into the anemic OS.
Apple's "OS" updates typically focus on end-user applications that I don't use and never intend to. Meanwhile the core of the OS, and even the desktop environment, feels stagnant compared to many Linux distros.
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’m in the same boat. I bought mine back in 2021 and honestly I don’t regret my decision. It’s my main software development of music production computer plus every Sunday night I get to play counterstrike with the boys by dual booting into Windows. I’m able to service repair and upgrade it myself and one day when I’m ready to move on I’ll use it as my home server. The crazy thing is that my next upgrade will be going back to a MacBook Pro most likely because the thunderbolt connectivity will be able to handle the Blackmagic 4 camera broadcast capture card and NVME PCIe storage card that are in my Mac Pro right now through some external enclosure.
The only real drawback that I’ve experienced with the Mac Pro has been the lack of support for large language models on the AMD GPU due to Apple's lacklustre metal drivers but I’ve been working with a couple of other developers to port a MoltenVK translation layer to Ollama that enables LLM’s on the GPU. We’re trying to get it on the main branch since testing has gone well.
One thing a lot of commenters in this thread are overlooking is that this is the death nell for repairable and upgradable computing for Mac, which is super disappointing.
Studios are repairable. Upgrading is being deprecated however, and I’m not sure that’s bad for Apple. It may not be bad for the end user either - it feels like external TB/USB peripherals might have a longer life transferred between computers than an internal PCIe version - and a larger market as they will work with any Mac.
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.
reply