Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[audiotweak]

Hi;

I have a very resolute yet musical sounding system.
I did find that there is a big difference in setting the buffering from 100ms to 50ms, the sound in tighter and more precise, could you see "if at all" possible in future updates offer a sliding scale "by increments" that will allow to fine tune say 60 or 63/4/5 etc...?
This would be great especially if the CPU can't handle 50ms but enough margin allows one to be at least as close to the 50 mark as one can get?

I find that your MC20 does not offer much in the way of improvements on the sonic front against your previous already excellent MC19 to warrant an upgrade just yet, however, in my opinion this idea could change the game quite a bit.

[glynor]

I'm not sure what you're asking for here.  This sentence fragment is a bit confusing:

offer a sliding scale "by increments" that will allow to fine tune say 60 or 63/4/5 etc...?

I'll assume you meant a slider that allows you to select more granular values than the dropdown buffering setting in there now (so "you could set 63, or 4, or 5, or whatever"), and not that 63/4/5 is some kind of crazy vector that doesn't apply here.

Hmmm...

On one hand, the control would work just fine as a slider bar.  And the math they use to calculate the buffer size could probably accept any integer value for ms.  On the other hand, it would make it just a bit more confusing for "normal people" to fix a problem.  Too many fiddly knobs are scary.  Too many choices (when you don't know what to pick), overwhelm.  If you just have a problem where your music is skipping, MC has a few choices you can pick from (and try one after the other until you find one that is reliable). It doesn't overwhelm with choice, but you can "dial in" the latency a bit.

And there's the rub.  The buffering setting only impacts latency.  Unless your DAC's (or its driver) is broken, the only difference between 100ms of buffering and 400ms of buffering is that when you click Play (or Stop, or change the volume) the higher buffering setting will take 300 ms extra before the music "reacts" and the change is applied.

With a low buffering setting, MC is more responsive.  When you hit play, the music starts faster.  When you hit stop, it stops faster.  The downside is that if the CPU and DAC clocks don't match right (or the DAC driver adds additional latency) you can end up overrunning the buffer, which causes a "skip" in the music.  Whether you overrun the buffer at a particular setting isn't a function of how powerful your CPU is, generally (unless you have complex convolution DSP effects applied or something), but a function of the DAC and its driver.  And, there is already a "lowest supported hardware" option you can pick, if your stuff is fast enough and well behaved enough to let you.

And a human can't easily detect that kind of latency difference when it happens a single time and there is no frame of reference.  The scale is too small.  There's all kinds of latency within you, in the same ranges, and it varies depending on what you're doing at the moment.  Your visual system has about 100ms of latency, and your auditory system has a different latency (around 30ms). And when you're receiving multiple sensory inputs simultaneously (looking at a button on-screen, clicking on a mouse, and hearing the result) you have even higher latency (depending on the task at hand), often between 130 - 180ms.  This has been studied thoroughly, but here's an interesting paper on the subject [PDF].

So... If you are saying it sounds "better" (what does that mean?) with specific amounts of latency then I'd say either:

1. You are super-human and very concerned about MC feeling responsive when you start and stop playback.
2. Your DAC is broken or has a very cruddy and temperamental driver (which I wouldn't trust anyway).
3. It is placebo.

So...

I don't work for JRiver, and I can't control what they do or do not add to MC, but... The premise of the request seems needless and based on a fundamental misunderstanding of what the buffer does.  So color me skeptical.

[theoctavist]

what the OP is experiencing is absolutely, definitely Expectation Bias.   

Please do yourself a favor OP and read this excelllent book on digital audio.


http://www.amazon.com/Digital-Audio-Explained-For-Engineer/dp/141960001X

[InflatableMouse]

what the OP is experiencing is absolutely, definitely Expectation Bias.   

While I tend to agree, I think you put that a bit too strong.

There can be driver issues, clock issues. If some buffer setting causes an incompatibility with a driver or DAC itself it is not impossible to run into an audible issue.

Let's keep an open mind.

[glynor]

There can be driver issues, clock issues. If some buffer setting causes an incompatibility with a driver or DAC itself it is not impossible to run into an audible issue.

I agree somewhat.  Buffering settings can cause problems (clicks, pops, and buffer underruns and other "obvious, serious" problems) with DACs and drivers that are...

Well, lets just say sub-optimal.

But it absolutely is NOT a situation where there will be a difference between a buffering setting of say 50ms and 52ms.  There is no reasonable need to have that kind of granularity (which no human will be able to detect).  If 100 doesn't work, then try 50 or 200.  It doesn't matter so long as one of them works (and working is a binary "works right or doesn't work right" state).

[InflatableMouse]

I agree somewhat.  Buffering settings can cause problems (clicks, pops, and buffer underruns and other "obvious, serious" problems) with DACs and drivers that are...

Well, lets just say sub-optimal.

But it absolutely is NOT a situation where there will be a difference between a buffering setting of say 50ms and 52ms.  There is no reasonable need to have that kind of granularity (which no human will be able to detect).  If 100 doesn't work, then try 50 or 200.  It doesn't matter so long as one of them works (and working is a binary "works right or doesn't work right" state).

Definitely.

I wasn't trying to defend the request for a more granular setting, I merely wanted to tone down that strong message that audiotweak couldn't be hearing anything. If all things are working as they are supposed to, it is true he shouldn't hear any difference. I just wanted us to keep an open mind that there can be other things going on that we can't see, that's all.

The buffering settings in MC are fine if you ask me. If that causes audiotweak to hear something going wrong, I think the real cause is elsewhere (ie, drivers, DAC, whatever).