It's survived for 20 years despite having none. It will continue as long as there are interested developers.
Just going from the dinky 256GB SSD your 6000 machine comes with to a more reasonable 2TB actually takes you to 6800.
Furthermore for this very substantial price you are buying a machine on an arch they are in the process of abandoning a bigger issue than the price.
To recap in 2013 the trash can came out. It was I guess OK but by 2015 its specs were noncompetitive. Between 2015-most of 2019 there was no real great answer for a mac tower. At the cusp of 2020 the new tower emerged followed 1 year later by the announcement that everything is moving to arm sooner or later.
Out of the last 8 years there has been one year in which it was a great year to get a mac tower and only if you are rich.
Assuming that this is true (which it is based off of the other comments) then that is EASILY worth the extra 4000 or even 10.000 USD to someone who needs real-time audio to do their recording or other audio creation job.
When I became a professional (in another field than audio/music) I developed 0 tolerance for tech that didn't work or that has me fiddle around with it for hours to work. It financially just doesn't make any sense to spend your time on that. It also doesn't make any sense from a mental health and free-time point of view.
I think that was the point (even though I'm not knowledgeable on the subject, other than having spent many day of my hobby-life trying to get Cubase to record with audio monitor (VST) without jittery latency on Windows and utterly failed).
People who aren't in the industry don't really realize that the Mac Mini is the entry-level into audio production for most people (iMac is the same for video). It has just enough to get started, and when you're making the big bucks the Mac Pro is in fact affordable for what you get.
Developers only see MacBooks for so long that they forget the rest of the product line exists, yet it's there for a reason.
http://www.tunetrackersystems.com/command-center-system-pack...
They have another system at the bottom of the page for a mere 1600 USD.
The very first versions of this product are essentially BeOS, plus an existing MP3-player type application, plus a little bit of software glue, the right off-the-shelf hardware and the know-how to use it for radio broadcast.
It's definitely one of those products some HN regulars would dismiss as "I could basically make that in an hour". Me too. But, after an hour nobody else can maintain it and it doesn't work on anybody else's computer. The hard work is in turning that into a product that generates some net revenue, which is mostly non-technical work.
Not knocking this Caster, but it might also be the ONLY Haiku OS commercial system
I believe Haiku did eventually fix some of the most egregious mistakes in their audio handling for example for years if you played silence it made everything else quieter, which is a classic goof†. But it's a long way from ideal for this application. You can of course use anything, if your hobby is making music with Haiku, knock yourself out, same with a ZX Spectrum or a toy xylophone, but yeah, not ideal.
† How do I mix samples for N channels together? Adding them together and dividing by N ought to work right? No.
BeOS kernel allows unique app access to a shared memory area, eliminating memory copies when sharing data. When creating the shared area, media apps can set several media access flags to engage the “fast path” if the devices have that buffer. These days modern graphics API’s (eg. Vulkan) offer the same buffer creation hints to help the driver figure out where to best allocate memory (device local, host accessible etc). Because not all memory is equal.
I’ve used both ffmpeg API and BMediaKit (I’m the author of a Haiku native video editor, https://github.com/smallstepforman/Medo). The BMediaKit API is trivially easy to use. ffmpeg is notoriously convoluted. Likewise, the native GUI API is also a pleasure to use. This is why my open source media editor is Haiku native (and not cross platform).
Hyperbole aside, I'm glad someone was looking at the audio situation, but this one seemed to knock me out of the game on every machine that received it. Examples of common scenarios for me: I can't have firefox open and virtualbox at the same time, or bitwig and firefox, or visual studio and audacious. Common pairs of apps cause a bitrate mismatch for whatever reason, and everything sounds like a heavily bitcrushed and ring modulated signal.
The exception to this are machines that were installed with pipewire, rather than upgraded to pipewire. Also, using Cadence, a router type app helps, but inconsistently.
Otherwise, have you raised the issue at https://gitlab.freedesktop.org/pipewire/pipewire/-/issues ? They're pretty responsive.
Even with PREEMPT_RT, I can't even run 2ms pipelines without xruns.
I don't think this is within the realm of fixable. Linux simply isn't a good design for this. Kernel too large and unpredictable. Who knows when or if execution will return to userspace.
Ftr, on Pipewire on a Dell xps with iRig2, I'm getting 4.6ms reported with just PREEMPT. An xrun every few minutes if I try to go to ~2ms. I suspect I could get that working reliably with RT.
So, 5ms is less than two metres. When COVID-19 forced you to stand a little further away from people, did you find it added "an eternity" of latency to everything? No? You barely noticed? Right.
One exercise that's interesting is you can build a physical loop (e.g. speaker plus microphone) and play with how long it takes samples to leave your software, turn into audio, then re-enter and come back to your software. You might find that to your disappointment a software stack may be giving you just 256 samples of latency but your hardware adds say 8 milliseconds on top of that.
This approach also helps you ensure you're doing apples to apples comparisons.
In no way is it acceptable for Linux to add 5ms to the chain.