[munificent]

I don't know. When it comes to real-time audio... imagine a huge festival with a giant wall of speakers blasting at the audience. If the audio playback glitches and you something like a 22kHz buzz (alternating two samples), that is a lot of fried ears.

[wizardforhire]

This scenario is the stuff of nightmares for me!

When you have 100k people paying $500 to the sky is the limit, failure is not an option. Increasingly audio engineers and subsequently performers are at the mercy of the latest jr developers who don’t have to live with the failures of their short sightedness. Grimes’ Coachella set case in point. Wholly due to pioneer ignoring their users for over a decade. Sometimes we don’t have 3 days to copy files to a usb drive but I digress.

[PaulDavisThe1st]

Apparently, failure was an option. Just not a very popular one.

[fxtentacle]

Grimes failure was still pleasant when you compare it to the mayhem you get when the DSP inside the amplifier system glitches for a few samples.

What do you think happens a dense crowd of 500+ people suddenly starts to have excruciating ear pain?

[jalk]

Is this something that happens often or are you simply speculating?

[munificent]

My understanding is that in practice, for very large shows, electronic musicians have fully redundant computer setups running in parallel and some hardware that will switch over instantly if one fails.

For example, here is one rig:

https://www.reddit.com/r/ableton/comments/7y2u3o/ableton_mai...

It uses a Radial SW8 to automatically switch between the redundant machines if one flakes out:

https://www.radialeng.com/product/sw8

[lomase]

If failure is not an option you bring 2 computers to every gig, burn CDs, and bring your vinyls.

Grimes is a "dj" that does not understand the software. Fixin that problem is one fucking click on the interface.

[alanbernstein]

Heh, I thought it was odd you referenced a ten year old show, but I guess she made a similar mistake twice. Her 2014 Coachella set was a total mess.

[ssfrr]

But you'll never be 100% sure. Most musicians aren't willing to pay for NASA-level QA and custom hardware running an RTOS, and even that doesn't guarantee perfect software.

We're always dealing with risk and trade-offs. Maybe you avoid a locking `atomic` synchronization point by implementing a more complicated lock-free ringbuffer, but in the process you introduce some other bug that has you dumping uninitialized memory into the DAC.

I think the advice in TFA is totally reasonable and worth following. I'm just saying that there may be cases where it's OK to violate some of these rules. I'd love to see more data to help inform those decisions.

This isn't even in opposition to the article, which says explicitly:

>Some low-level audio libraries such as JACK or CoreAudio use these techniques internally, but you need to be sure you know what you’re doing, that you understand your thread priorities and the exact scheduler behavior on each target operating system (and OS kernel version). Don’t extrapolate or make assumptions

[wholinator2]

Off topic but does TFA still anyways mean "The Fucking Article"? In my personal understanding it came from people telling others to "read tfa". But to see the term used ubiquitously referring to "the article" but keeping the profanity just seems kinda strange to me. We could say something like "TA" and omit the "fucking" but maybe it actually means something completely different and my personal lore has just detached from the zeitgeist

[mardifoufs]

I think it does mean "the fucking article", but I also think a lot of people use it as "the featured article". I agree with you though, it's a bit confusing sometimes as the less nice usage is still also common hahaha.