Does a 3D printer like this not actually require high-precision data to work correctly?
That said, there is measurable and audible differences between a stock audio output and a high end (or even prosumer) audio output. A nice 24 bit audio box could, possibly, be a useful upgrade in the future...when the mechanics finally catch up. But, I suspect it'll be years before the mechanical side of this design is precise enough to even show the errors in a 16 bit output. If ever...
Also, consider that not all audio glitches are of the type that cause zeroes to be emitted. Some audio glitches are known as buffer underruns, where the ring buffer holding audio is not filled up in time, and eventually runs out, causing the same few milliseconds of audio to play over and over again until more audio makes it into the buffer.
Only if you consider a centered rod of minimum thickness "valid".
Certainly, it would be bad if this thing relied on every last available bit of audio bandwidth all the way up to 22.05 Khz, but there's no particular reason to do that.
The people I talk to who do professional audio recording and mixing insist that it is still a difficult problem; it was back when I did mixing (early to mid 2000s, not 'the 90s'). The prevalence of custom APIs for glitch-free low-latency audio playback like JACK and ASIO suggests to me that you still can't rely on just feeding samples to the OS and having them come out of the sound card at the appropriate rate 100% of the time.
FWIW, Windows introduced an entirely new audio stack in Vista that was tuned specifically to address these problems. Their first iteration managed to cripple ethernet bandwidth because of the scheduling requirements imposed for glitch-free audio.
I still can't use Linux as my primary OS for audiovisual work because there are still issues with getting many channels of low latency, high resolution, audio playing and recording reliably.
But, the issues you describe as they apply to this task are mostly a long solved problem, at least for very simple tasks, like reliably playing 16 bit, 44.1 kHz, stereo audio. Honestly, there's never been a time that I can remember when I couldn't reliably play a stereo 16 bit, 44.1k, file back on a Linux system...going back to 1995, or so, when I first started using Linux. The problems come when you demand a little more of the system.
Once again, errors of the level that exist today (which are completely inaudible to even trained ears in most cases), in terms of latency, jitter, dropouts, etc. are so tiny and insignificant that they would be impossible for the current hardware to replicate. The hardware is so much slower than the input signal that noise from the audio signal will be lost in the much larger noise of the hardware. You can see the hardware noise in the printed objects. It's vastly larger than anything the computer output is going to screw up, and it'll be many generations before that stops being true (and, by then, maybe Linux will finally have its act together on audio).
Windows, BTW, finally does have its act together on audio, and has for five+ years. I can reliably play a couple dozen 96k 24 bit tracks while recording more on slightly high end laptop. Obviously Mac is also solid on this front.
Latency and glitching can become an issue when you're trying to record and monitor in real time while also operating plugins and multiple tracks. That's not the case here.
In passing, I'll tell you what is really a problem on current iterations of Windows: MIDI over USB. Audio is OK, MIDI is atrocious.
But, it's sad that any MIDI device can possibly have problems anywhere so long after its invention. I have a MIDI interface on a Commodore 64 that works reliably! Likewise, I used to do sequencing on an Amiga...worked fine for MIDI. Multi-track 16 bit audio was more of a challenge on such a small machine (started doing digital multitrack work with an Amiga 2000 with a 7.14Mhz CPU).
Boots Riley of the Coup talked about using an ST for many, many years after it was out of date. I think he was using it up until Party Music (released in 2001, but it might have been the prior record. Atari Teenage Riot also keep pounding away on their STs well past their prime.
I use a C64 and a Game Boy for music production these days; but I mostly play the 64 live (using the keyboard...not even a MIDI keyboard of piano overlay) and the Game Boy just exists as an independent music device. I've never tried combining its output with anything else. But, probably will eventually. If I were to find an Amiga 1200 or one of the latter day STs, in really good shape for not a lot of money, I'd probably pick it up. But, there are so many collectors of the old machines now, and so few remain in working condition, that it's not common to find them. I need to acquire a backup C64, though, for sure. I don't think there's good resources for repairing them the way there were when I was a kid.
When professional audio people talk about the difficulties of glitch-free playback, they're talking about running their CPU at near 100% utilisation with 64 or 128 samples of buffer. Playing back a clean and glitch-free audio stream is trivial and has been for years.
Note also that the audio input allows playback from an mp3 player or other sources, suggesting the audio can be wholly precomputed. Imagine how useful that could be in places like Africa so that you could print thing without necessarily needing a high-power device like a laptop.
This is an awesome idea. You could broadcast objects over FM radio! Just like they used to do for software when early home computers used cassette tapes for storage.
Including a low cost USB adapter (even an audio one) that is tested and calibrated to work with the printer could prevent a lot of headaches in setting this up.
On the other side of the concept of using audio as their output system, what would a cube sound like if played through speakers instead of through their printer? And how would a Mozart symphony look when printed?
And yes, I am going to get one just so I can see how Pink Floyd compares to Daft Punk when printed.