longview posted:

I used to get minor headaches from listening to music for too long without a crossfeed filter activated, it's not so much improving the soundstage so much as it's emulating a stereo speaker set in your headphones. IMO it should be implemented in hardware in a "proper" headphone amplifier, it's much more useful than the 6 dB bass boost that most amplifiers come with.

Combat Pretzel posted:

A lot of smartphones do that when they detect a headphone plugged in (apparently they can discern between headphones and aux), and audio gets crappy sideswipes on reviews because of that. Usually the stereo crosstalk goes from -90dB to -60dB when using headphones.

some lunatic posted:

Namely, I was hoping someone would be able to tell me why, in no uncertain terms, they do in fact make a difference in the way my music sounds coming through my hi-fi. In many ways and for many reasons I wished they made no difference at all. I wish they were just some audiophile nonsense that I could plug in, listen to, unplug, and simply shrug at their utter ineffectualness. But that's just not how these things work.

he goes on posted:

These changes are also cumulative. With all Vodka cable in my system, from NAS to switch and from switch to MacBook, there was a greater level of perceived clarity and scale as compared to swapping out just one of the cables. If I were to pick which cable in the chain made the most difference, I'd say the one that ran from the switch to the MacBook.

grack posted:

That's okay. There's a thread on head-fi right now talking burning in cables for 400 hours. Not like, speaker cable, headphone cable. From an iPod.

Blistex posted:

The only thing that I can come up with that's similar are people who believe in faith healers. Although that isn't even a fair comparison, as the placebo effect is an actual thing that has been scientifically documented with double blind tests, as opposed to cable burn in.

Blistex posted:

The only thing that I can come up with that's similar are people who believe in faith healers. Although that isn't even a fair comparison, as the placebo effect is an actual thing that has been scientifically documented with double blind tests, as opposed to cable burn in.

quote:

Is the reviewer aware that digital data carried over a TCP/IP stream is subject to a parity check, and ergo, by design, it is literally impossible for the cable to alter the stream? If the cable did alter a bit, the parity check picks it up and re-requests it, leading to a bit-perfect representation on the other end. Additionally, any breakdowns that went uncorrected (say, from a severely failing cable) would result in complete breaks in the transit, making all the signal fail.

For instance, when I copy 'War and Peace.txt' over an ethernet cable I get 'War and Peace.txt.' on the other end. Every letter is in the same place on both devices. If a failure does occur (say, a bad sector of the HDD made the file marginally corrupt on writing) then the failure would be obvious - whole sections of the book would become garbage. Random error doesn't produce random words any more than random error can "increase clarity".

It doesn't subtlely re-write itself, so that the prose carries a little less emotion in certain sections, or events don't play out a little differently. To suggest that a completely random corruption could do so would be absurd, which is basically how articles like this look.

I strongly urge anyone spending this amount of money on digital cables to instead spend the money on a basic networking course, so that you can come back to the page here and join in telling people why 010100 will always arrive as 010100 and any time 010100 arrives will sound identical to any other time 010100 arrives

Khablam posted:

My comment on that article, which I entitled "It's Digital Data. Read a book"


... posted since they will likely take it down

RoadCrewWorker posted:

To be fair the quote is "there was a greater level of perceived clarity and scale", so the logical chain is really just "loads of money spent -> larger psychological investment -> altered psychological perception".

quote:

This operating system uses a realtime kernel. The goal of realtime is to give audio processes priority, to prevent interruption by non-audio processes (those that aren’t system critical). In studio production environments these interruptions can result in latency, which is a problem for recording. We’re not concerned with latency, but we can do without audio processes being interrupted. The theory is that these interruptions could disrupt the precision of the clock timing and result in jitter. Of course there are other factors that affect your sound quality, particularly your player’s driver. However, there’s no question realtime operation is different; a little Nu-Force headphone amp requires a latency setting of 17.4ns to remain stable with a generic kernel and can go as low as 8.6ns with the realtime kernel.

quote:

Khablam's post is, IMO, just a repeat of the old objecivist[sic] refrain that it's digital and bits are bits and therefore the ethernet cable cannot make any difference

cheese-cube posted:

Sounds like bullshit, can someone confirm?

Khablam posted:

Guys I am cray cray for thinking 0=0 and 1=1


Like, he's literally explaining why I am right, whilst insinuating it's some insane position.

eggsovereasy posted:

Your entire digital sound system is just packed with noise desperately searching for a DAC so it can burst out and ruin everything you listen to.

KozmoNaut posted:

The thing I find really odd is that none of these tweaks are ever perceived as detrimental to the sound. It's always more expensive = better sound.

Combat Pretzel posted:

Soundcards/-chips have a hardware buffer they're playing from, that needs to be filled. Timing matters jack poo poo, since it's way larger than a few samples. The only thing that can happen are buffer underruns, which results in short bursts of silence or garbage data (depending on the card). Nothing in the OS will affect jitter and whatever the gently caress fancy words they use.

cheese-cube posted:

Yeah that's what I thought. You'd have to be running on some pretty lovely hardware to encounter buffer under-runs.

Edit: or have your settings seriously misconfigured.

WanderingKid posted:

You don't need lovely hardware, although you can get drop outs because your PC is very old and you are running very expensive signal processing, or your soundcard has lovely drivers or misconfigured ASIO or DMA buffer settings at high cpu loads.

High cpu loads could be a result of so many things - badly designed signal processors/generators, inefficient/expensive processes (like real time convolution), stupid oversampling. Those are all on the software design level. I don't design software, just use it as a tool to make sounds.

On the user side, your music projects and workflow could just be inefficient, i.e. bad channel routing and use of send buses resulting in lots of duplication of CPU destroying plugins.

Nevertheless, you will notice when you are dropping buffers. You get loud clicking noises or very short bursts of noise (that sound like clicks), sound drop outs, "stuttering". The most common solution is to increase the buffer size until you no longer get dropouts. Eventually it will result in a big enough delay between key press and sound, that you can't play a keyboard in time.

If you want to look into the mechanics of it, you need to go deep into Windows internals and how interrupt handling and direct memory access work.

Its a different mechanism to jitter which (I think) is a time domain quantization error. I don't build AD/DA converters so I don't really know what it is, because its an engineering thing.

I sort of know what a quantization error is because some of the tools I use let you do things like truncation (discarding bits) and decimation (discarding samples). If you discard enough bits the sound just collapses into noise but its a distinctive sort of noise. It isn't random.

For the kind of bit depths that commercial software and industry standards operates at, things like dither and quantization error just define noise floor.

Under specific and typically unnatural listening conditions you may be able to hear it. For example, listening to a fade out of a pure (audio frequency) sine wave at ungodly listening levels in a room with perfectly controlled acoustics. Ehhh, I dunno. The only reason I even encountered this poo poo is because of the prevalence of home mastering software. All of that stuff is still in engineering territory.

I dabbled with mastering my own songs for a bit but the conclusion I arrived at was this: don't try that poo poo at home. Pay a mastering engineer to do it for you or train to be a mastering engineer. Apart from the lack of technical expertise, you don't think of your own work the same way other people do, because you know how the auditory illusion is constructed.

WanderingKid posted:

quote:

bad channel routing and use of send buses resulting in lots of duplication of CPU destroying plugins

ohgodwhat posted:

If I'm understanding this correctly, you're just providing an example of when buffer underrun can happen even with modern hardware? The rest just seemed like you trying to explain stuff that you're not really comfortable with yourself. I'm not sure that really deserves so much scorn...

WanderingKid posted:

Its easier to get a grasp of what quantization noise is when you literally throw away 15 out of 16 bits and listen to what the result sounds like.

quote:

I sort of know what a quantization error is because some of the tools I use let you do things like truncation and decimation

Khablam posted:

A quantization error is the sampling being wrong (same input leading to different outputs), what you're experiencing is the sample being too non-specific (many inputs leading to the same output) to represent anything we would consider music, or even sound at that point . You're not hearing noise, you have made it impossible to do so; you don't have the bitrate for it.

breaks posted:

after reading back a bit further, I'm not sure how the thread really got on this topic)