Buffer size & USB Streaming Mode

Hello!

I've always had my USB Streaming Mode and ASIO Buffer Size at default, which is "Reliable" and "Auto".
My question is: Is there an optimal setting or something I should aim for?
Obviously, lower buffer size can give distortion, and very high buffer size make it take longer to change song etc.
Would it be better to set it to a happy medium rather then "Auto"?

And what about USB Streaming Mode?
Cant decide if I can hear a difference when trying out the different modes, but "Minimal Latency" sure sounds attractive.
Ive seen some people recommend to set it at "Extra reliable" too.

Anyone who have a clue about this?

Thank you!

 

Are you hearing all your music? Are there any gaps?

Yes you are and no there aren't? Don't even think about this stuff.

Yes, it does --- which is why there are entire websites devoted to this stuff. Latency is of no consequence whatsoever when listening to music unless you get fed up waiting for the music to start after pressing play.

 

These settings exists purely to allow you to tweak latency vs. avoiding drop-outs.

If you're not getting drop-outs and/or clicks in your playback then I would leave them alone (I'm assuming the "distortion" you're talking about with a smaller buffer is this, because otherwise it doesn't make any sense).

The ability to change these settings is required because Windows is not a RTOS and in professional settings we care a lot more about latency, so we want to be able to tweak it to be as small as possible without causing drop-outs due to the buffer(s) emptying. There are two independent schemes for buffering at work, first in the USB Streaming Layer and then in the ASIO layer. Just for fun, they're specified differently, one in terms of size the other in terms of time.

So, the values for "USB Streaming Mode" range from "Minimum Latency" (which is 1 millisecond, and, in fact, is the shortest value supported by the bus interface/driver) up to 32 milliseconds for "Extra Safe". But, again, all this does is affect the size of the buffer (bit rate/1000 x duration).

 

Can you qualify this? I'm aware that latency matters a lot in certain recording or monitoring scenarios, but my explanation would be dumb, because I've never been there and done it. Just read about stuff over the years.

The word "professional" can push buttons. Like mine, for example. I call myself a recovering audiophile, but I used to prefer reviews in SoundOnSound to reviews in Audiophile. "professional" can make something look attractive, when, in the wrong context it actually isn't.

I suppose I'm saying... lets save a soul here! Let's help this guy not to become a fully-fledged member of computeraudiophile!

 

I know that my midi controller will get huge delays if I dont have latency pretty low.

 

So you are doing more than just listening to music?

I'm always careful to qualify my latency does not matter rant with for music listeners, or words to that effect. For music makers, recorders, etc, it can certainly matter.

 

Yes I use FL Studio, but this thread was aimed at music, if it effects music, which it seems like it doesnt do, other then playback delays

 

"Professional" is probably poor choice of nomenclature on my part here. I should have said "studio", "recording", "monitoring" or "mixing", and even then I tend to lump those, mentally, into a single category of "music production" and label it "professional" usage (even when it's just done for fun).

Having minimal latency is important when dealing with any kind of input/response system so that you can have the most immediate feedback on what your input/change is doing to the sound. If I move a slider on my control surface, be it to change the relative level of a given track, or to adjust a parameter in EQ, or to flip-phase on a track (etc.) I don't want the audible results to lag that input. Some lag is unavoidable, but the less the better, otherwise you can wind up chasing a moving target.

It's a bit like the delayed response you get in an aircraft to a control input. While the control surface on the aircraft may respond instantly (very much dependent on which control surface and what sort of aircraft), it's effect on overcoming the inertia of the body is slower and if you're not careful you wind up using bigger inputs than you need to get a quick response and then chasing a point of equilibrium back and forth to settle things down. A similar situation is in correcting an extreme skid in a car.

Anyway, back in the music world ...

There are also multiple sources of latency ... particularly with software instruments and, especially, effects/filter plug-ins and virtual patch-boards. And if you run those on multiple machines, then you need to keep those in sync and manage latency between them. Which is where we'd devolve into the world of master word-clocks, time-base generators and time-codes starts to be not just useful, but critical.

But for just listening to music ... you're just trading off interface responsiveness (how long does it take for the music to start/stop) vs. the probability that the OS takes longer to service your interrupt request for the next packet of USB data than there is available data in the buffer. As long as the buffer never empties, all is good, but if it does get exhausted you'll get drop-outs and glitches.

Hope that makes sense!