
Improved audio rendering with an optimised version of memcpy (2013) - mpweiher
https://www.audioasylum.com/forums/pcaudio/messages/11/119979.html
======
mschaef
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/](https://www.cnet.com/news/denons-500-ethernet-cable/)

~~~
Kenji
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$.

~~~
dom0
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).

~~~
scns
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.

------
dwarman
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:)

------
kabdib
_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..."

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

------
phkamp
The word you are looking for here is "audiohomeopathy"

~~~
pauldelany
"phoneopathy" sounds better :)

------
userbinator
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.

~~~
coldtea
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?

------
darasan
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...](http://gizmodo.com/305549/james-randi-offers-1-million-if-audiophiles-
can-prove-7250-speaker-cables-are-better)

------
dom0
Well that's just a curious case of audiofoolery.

~~~
jalk
audiopathic behavior

------
Asooka
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.

~~~
Dylan16807
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.

------
azernik
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.

~~~
dom0
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.

~~~
asveikau
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.

~~~
dom0
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.

