Improved audio rendering with an optimised version of memcpy (2013) | Hacker News Reader

Improved audio rendering with an optimised version of memcpy (2013)

audioasylum.com

51 pointsmpweiher41 comments

This is so ridiculous that I can't tell if it's a joke or these people are even more delusional than the Pear Audio/Denon AKDL-1 crowd.

https://www.cnet.com/news/denons-500-ethernet-cable/

To really hear the difference a $500 Ethernet cable can make, you'll also want to tape some Magic Pebbles[0] to that bad boy.

[0] http://www.machinadynamica.com/machina31.htm

I can't figure out if this is a joke or not. Amazing how far out some of these audiophiles are.

A colleague of mine has two master's degrees from a prestigious university, one of them is physics, and he buys bass guitar cables for 120$ and more because he believes he hears a difference between those and those that cost, say, 30$.

Instrument cables actually sound a bit different; their capacitance influences the frequency response. The price doesn't really influence that much, though. Very cheap cables can be noisy (which means that they are microphonic, i.e. generate voltages in response to being moved / dragged about).

This a hundred times. A passive guitar or bass pickup is going to be dampened by the low pass filter which consists of the capacitance of the cable and the coil of the pickup and the input impendance of the preamp. Linesignals, or instruments with inbuilt active circuits are not affected.

That's ridiculous, but somewhat understandable. That's an analog signal, so subtle differences in how it's transmitted could at least theoretically have an effect.

Doing this in the digital realm is a whole extra level of crazy.

Is it possible to get an MS in the hard sciences and remain ignorant of the placebo effect?

> Is it possible to get an MS in the hard sciences and remain ignorant of the placebo effect?

Since the placebo effect is really only particularly relevant in some "human-subject sciences" (medical and some social sciences), sure.

But the question here seems to be more whether someone can get an MS in the hard sciences without applying scientific thinking to all decisions in their life, for which the answer is obviously yes. It's actually to be expected to a certain extent; not every decision is worth the same amount of attention, and subjective impression is often a good enough basis when the cost of a bad decision is fairly low. (And I suspect most people who criticize particular instances of this in others do it plenty themselves.)

But the question here seems to be more whether someone can get an MS in the hard sciences without applying scientific thinking to all decisions in their life, for which the answer is obviously yes

Also, in some places, there are people who can get an MS in the hard sciences without applying scientific thinking much at all. Fortunately, they (mostly) get weeded out when they're called upon to do actual work in whatever field they claimed to have studied.

The issue becomes really serious when playing 96 audio files simultaneously. As in: game audio or multitracking DAW (where 24 or more would be recording at the same time, not merely playing back). Every cycle counts there, any cycle not moving audio is a wasted cycle. Indeed, turns out (surprised me when I moved into this field), audio of any paralellism is the hardest Hard Real Time process in a computer audio system, or a game console, or pro audio mixing desks and synth racks. The human ear is the most time critical of our senses; you can drop a video frame and harly anyone notices, but everyone bitches about a dropped audio frame.

ps: this stuff is also achieved in iOS devices. Mind-blowing as that may seem.

pps: just playing audio files is not, in general, latency sensitive, so larger buffers can mask more egregious cycle wasting in the setup and other overhead. Playing sound effect files (gunshots, squealing tires, etc) is however latency sensitive, and there can be many at the same time, so there we shoot for smaller buffers and pay more attention to overhead reduction. In both cases, however, we never start outputting from a buffer that is not filled. Cacheing issues mostly, and also scheduling. Usually that is shared memory, even core to core dual cache shared, with the audio handled in its own subsystem, so there are some very subtle issues at the extremes we work in.

(I'll leave the Monster cable manutroversy out of it here:)

Jaw drops

Opportunities here. "Oh, you want the audiophile quality version of the firmware? That's a separate download, from our degaussed and quantum-aligned servers, just a sec..."

I have long thought that I could make a fortune selling stuff to audiophiles, if only I had slightly fewer scruples.

The word you are looking for here is "audiohomeopathy"

"phoneopathy" sounds better :)

The irony is that optimised memcpy() which is anything but REP MOVS will probably be slower on modern x86 processors. Over the years, people have come up with (very large) code sequences for block copying which when benchmarked in isolation can be slightly faster than the native instruction, but the increased cache usage usually makes the advantage disappear or even become a disadvantage in a real application, as now there is less other critical-path code which remains in the cache.

Isn't the irony that the whole idea is BS in the first place, and memcpy has absolute no effect on the sound rendering quality?

REP MOVS has a fixed setup cost which needs to be amortized; so its slower for small sizes that for example SIMD. Though is faster for larger sizes (> 512 - 1024 bytes?)

Personally, I use 70s tube-effect memcpys() for that vintage sound.

Re cables etc - there was $1m dollars offered to anyone a few years back who could disprove the audiophile nonsense:

http://gizmodo.com/305549/james-randi-offers-1-million-if-au...

Well that's just a curious case of audiofoolery.

audiopathic behavior

There is, actually, one single instance I can think of where a custom memcpy would be better for an audio player than the compiler-provided memcpy. Some time ago Intel engineers advised that you should memcpy backwards on certain CPUs because it ended up being slightly faster. If you're copying a large enough buffer and running with tight enough latency (not sure how that would happen though), there's the very slight possibility that you might end up not copying the first new expected sample in time.

I think you're trying too hard to apply that interesting fact to the situation at hand. Audio bitrates are just not high enough to need it. And avoiding skipping generally means getting the first few bytes into the buffer fast enough, so starting at the other end would make it worse.

To people making fun - this is not about creating audio files, but rather about techniques to reduce latency and jitter when playing audio files. Similar to the crazy techniques that the VR folks like Carmack have proposed. Yes, indeed, audio files these days have WAY more information content them the human ear can distinguish, but if your playback has skips and assorted corruption that doesn't matter.

For example, one of the responses proposed pre-loading a large fully-rendered audio segment onto a DMA buffer to remove the CPU from the latency-sensitive pipeline entirely.

Reducing jitter for file playback is easy. Just use a huge buffer. Done. Latency doesn't matter because the whole file is available ahead of time.

Even if this did matter, it's still bullshit. Memcpy isn't going to add latency and jitter over some "optimized" copy routine. And C++ new certainly isn't going to be better than malloc, when it's almost certainly calling through to malloc.

If the song was recorded in 1991 and you're playing it now, that's 26 years of latency, no matter what.

One year longer and it would not be latency anymore, it would be hammertime.

(Sorry)

Audio codecs use memory-mapped ring buffers; as long as the driver's write pointer stays ahead of the codecs' read pointer there is no way to add jitter. Note that the codec doesn't care about the write pointer, if the driver forgets to update the buffer, the card will just play it over and over again. Sometimes that happens when a computer wakes up from stand-by. The result is quite characteristic.

you are describing a buffer over/under run. jitter is when a stream of serial audio data (such as most external usb/firewire/etc audio interfaces end up receiving) is not time-aligning it's frames/samples correctly with the clock of the codec (which should be the master clock) or other situations where the clocking of playback/recording differs from the derived "clock" of the streams boundaries.

The concepts you are mentioning (DMA and ring buffers) are heavily used but I don't think you have the layering right. In all APIs I have used, the codec library itself works with contiguous buffers typically on the heap, which end may up being copied into ring buffers or DMA buffers I will give you, but that is one abstraction above or below.

I meant the hardware with audio codec, though technically it would be the audio controller which has the buffers and control registers (which may/may not be the same chip, depending on the exact make, e.g. in HD Audio the controller is in the chipset, and the codec is a separate chip). Sorry for the confusion.

Why isn't it the audio codec's write pointer and the driver's read pointer?

Because this is about audio output?

I had that part figured out for myself, thanks for being patronizing while adding nothing.

Right, so the codec decodes the audio and writes it into the buffer, and the sound card (or driver) reads out of that buffer and plays the sound. Where am I going wrong?

"codec" here is the sound card.

Back in 1997-8, I ran across custom hardware that used this strategy to directly transfer large volumes of ADC data from the sampling hardware to a disk array. It made absolute sense given the the data volumes involved. (100-200MB/sec to persistent storage, which was a lot for commodity hardware back then.)

Audio is full orders of magnitude less data and this is on hardware that's 20 years newer. With any reasonable buffer size this is a slam dunk, unless perhaps you're really concerned about latency.(In which case automatically streaming multiple megabytes of audio data across DMA isn't going to help you either.)

>To people making fun - this is not about creating audio files, but rather about techniques to reduce latency and jitter when playing audio files.

They are more like techniques for creating April Fools jokes...

>For example, one of the responses proposed pre-loading a large fully-rendered audio segment onto a DMA buffer to remove the CPU from the latency-sensitive pipeline entirely.

You missed the fact that that response was taking the piss of the initial post...

"Taking the piss of" is not comprehensible in my (middle american) dialect. Please elaborate.

It may be also be used to refer to a ruse whereby a person is led to believe a plainly unbelievable fact for the purpose of ridicule of the subject, e.g. "Are you being serious?" "No, I'm just taking the piss."

https://en.wikipedia.org/wiki/Taking_the_piss

Reply on news.ycombinator.com