Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Playback Buffer, Hardware Buffer, Read-Ahead, Full File Buffering (Read 1284 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Playback Buffer, Hardware Buffer, Read-Ahead, Full File Buffering

Someone PLEASE make proper wiki entries for each of these things to define their differences.
The forums topics on these features are a mess.

Okay so the playback buffer obviously loads up your end-output in RAM, so that if ever there is a hiccup in the reading or decoding process, the buffer covers for it.
However, it is a constant duration, which to me means it will continue to decode and read data non-stop, maintaining that buffer duration at all times. This means effectively 0 downtime in Foobar function.
Additionally, even with massive 30 second buffers, it's clear that Foobar does not wait to fill that buffer before it starts playback. Okay fine.

I have READ on the forum that the Read-Ahead for local files is "similar" to the buffer, however it only READS data in advance, it does not decode it. Because the feature is data-capped, that means you have less time for things to go wrong on higher bitrate files. This is natural as before the file is decoded, you don't know the duration of the dataset without some approximations using bitrates in the metadata. Okay fine.
Now. How do these two interact? How do these two cross track boundaries?

Then we have the hardware buffer, which at a cursory glance I didn't see a good explanation for but the advance was not to touch it unless things aren't working. Well, I was getting stutters with default settings which is why I'm hear. I ASSUME if things are working CORRECTLY as one would expect, I wouldn't ever be encountering any stuttering. This is something new to me and I thought it was a result of my hard drive dying but upon replacing it I still had the issue when I never had it in the past. No idea what's changed.
In any case, I did a fresh Foobar install to the latest version to see how that goes but it's something that happens once in many hours so I'm not sure if that's solved it now or not so I'm here to figure out if maybe there's a buffer that can help with this.

Then we've got full file buffering. This seems somewhat self-explanatory but I'm still not quite sure how it interacts with the other 3 and in the forum there was someone who said that this would impact gapless-playback because it would interrupt track changes. This is clearly not the case as I've set it to 216000KB and have encountered no such issues.

In Windows power settings I currently have my hard drives set to sleep after 6 minutes. This is low enough that I think I would notice any issues with track switching considering the amount of large files I deal with, if having full file buffers were consequential.

Why do I have such a large buffer? Well I'm dealing with a laptop and I'm kind of looking to minimize hard drive activity for the sake of power as well as jostling concerns.
Ideally the thing just wakes up to buffer an entire song, preferably two, and then goes to sleep again until maybe a minute before the last buffered song ends so that it has time to spin up and buffer another 2 songs. This should leave plenty of room for that on the decoding end too.
Obviously ~216MB seems large for 2 songs, but I also want whole mixes to be buffered. Seemed like a good number to me.

Anyway obviously just like... Maxing out all the buffers would PROBABLY fix my issue, but I'd really rather do it somewhat responsibly/intelligently and the wiki really should have this information in there already.

Re: Playback Buffer, Hardware Buffer, Read-Ahead, Full File Buffering

Reply #1 –
Putting your hard drive to sleep every 6 minutes is a good way to kill it fast.  That's a little too low.  I turn that feature off and instead use system standby or hibernation as those two options will save you a lot more power.  Alternately you could just set your system up to be turned off manually, too.

The most power hungry component in a modern computer is usually the graphics card.  The second most power hungry component is usually the CPU.  CPUs are typically less power hungry than GPUs.  Storage devices typically aren't very power hungry unless you got a ton of them all running at once (i.e. a server with many hard drives or SSDs).  A single consumer grade hard drive isn't going to consume much power and even if you got two or three of them or if it's paired with an SSD it is still not going be as much as what the CPU and GPU probably draws.

If you're getting playback issues:
- Check your system load.
- Adjust buffer settings.
- Use a different output sampling rate.

Re: Playback Buffer, Hardware Buffer, Read-Ahead, Full File Buffering

Reply #2 –
You seem to have entirely missed the point of what I'm doing.
I'm still using my system, therefore putting it into standby or hibernation is not an option. I'm not turning off my system.
It's rare that I will have 6 minutes of inactivity while playing music, since most songs are less than 6 minutes long.
My power draw at the wall just listening to music is under 20W. A hard drive will easily take 5W of that. It's not insignificant at these levels. This is a laptop. Most of the power draw is likely from the monitor, not the CPU or GPU while I use it for basic web browsing, documents and music.

>Adjust buffer settings
WHICH buffer setting and HOW?

This doesn't help at all.
The wiki needs proper documentation.

Re: Playback Buffer, Hardware Buffer, Read-Ahead, Full File Buffering

Reply #3 –
Quote from: Cormy1 on
You seem to have entirely missed the point of what I'm doing.
I'm still using my system, therefore putting it into standby or hibernation is not an option. I'm not turning off my system.
It's rare that I will have 6 minutes of inactivity while playing music, since most songs are less than 6 minutes long.
My power draw at the wall just listening to music is under 20W. A hard drive will easily take 5W of that. It's not insignificant at these levels. This is a laptop. Most of the power draw is likely from the monitor, not the CPU or GPU while I use it for basic web browsing, documents and music.

>Adjust buffer settings
WHICH buffer setting and HOW?

This doesn't help at all.
The wiki needs proper documentation.

Laptops are designed to be energy efficient.  My desktop computer uses 3 times the power at idle compared to that.

The power settings I use for a laptop.
When plugged in = always on, just shut the lid when I'm not using it or turn it off if I won't be using it for extended period and unplug it.
When on battery = standby operation after an hour or two and hibernation a few hours afterwards.
When in a carrying bag = turn it off or hibernate manually before putting in the bag.

That aside I set the CPU utilization settings under power management and try moving the minimum to 100% and the max to 100% when plugged in and see if that helps with stuttering.  When on battery I set the minimum to be as low as possible to conserve battery life.

Random stutters assuming your playback buffer settings aren't too low can be caused by a variety of problems such as misbehaving devices and poorly configured system settings.  If a system is quite old, it can also be sign that you need an upgrade or newer computer.  Laptops age faster than desktops do.

I swap the laptop's hard drive for a solid state drive as well as that might improve system performance a lot and an SSD is just better for a laptop overall as they have no moving parts and will consume less power.

Re: Playback Buffer, Hardware Buffer, Read-Ahead, Full File Buffering

Reply #4 –
Quote
which is why I'm hear. I ASSUME if things are working CORRECTLY as one would expect, I wouldn't ever be encountering any stuttering.
You need buffers because your multitasking operating system is always multitasking and interrupting, even when you're only running one application.    The size buffer you need depends on what the operating system is doing, what background process are running, what any other applications are doing, and how powerful your processor is.

Oh...   Of course "higher-resolution" audio has to process more data so that generally requires bigger buffers too.

Re: Playback Buffer, Hardware Buffer, Read-Ahead, Full File Buffering

Reply #5 –
The buffering settings are pretty self explanatory and you seemed to understand them well. The playback buffer is the main buffer to help you against playback glitching and it must be constantly updated. That is the backbone where output components get the data needed by DAC.

The hardware buffer setting you wondered about only affects exclusive WASAPI output. It's a low-level buffer that is actually responsible for the data delivery from OS to the audio interface. Normally the drivers tell what size is optimimal but there is an override setting hidden in advanced preferences so user can try tweaking things if for some reason device manufacturer/driver programmer is wrong and defaults do not work. This is the very last buffer that playback thread needs to keep filled at all times from data taken from the foobar2000 playback buffer.
 
Quote from: Cormy1 on
I have READ on the forum that the Read-Ahead for local files is "similar" to the buffer, however it only READS data in advance, it does not decode it. Because the feature is data-capped, that means you have less time for things to go wrong on higher bitrate files. This is natural as before the file is decoded, you don't know the duration of the dataset without some approximations using bitrates in the metadata. Okay fine.
Now. How do these two interact? How do these two cross track boundaries?
Read-ahead buffer reads extra data from the track that is being decoded. Your output buffer duration defines how much in advance the next track will start decoding. By default output buffer is 1000 ms, 1 second. So one second before current track is done playing the next track will start decoding. If read-ahead is configured, extra data from the next track will be read into memory.

Quote from: Cormy1 on
Then we've got full file buffering. This seems somewhat self-explanatory but I'm still not quite sure how it interacts with the other 3 and in the forum there was someone who said that this would impact gapless-playback because it would interrupt track changes. This is clearly not the case as I've set it to 216000KB and have encountered no such issues.
I will continue to say that it can affect gapless playback. But whether it does depends on how long playback buffer you have and how fast the next track can be fully loaded. If you don't have enough playback data buffered for the duration it takes to fully load next track into memory and start decoding new data from it, you will have a gap.

Quote from: Cormy1 on
In Windows power settings I currently have my hard drives set to sleep after 6 minutes.
As you were told, this sounds like a bad idea. Powering on and off isn't good for the health of spinning hard drive.

Quote from: Cormy1 on
Ideally the thing just wakes up to buffer an entire song, preferably two
You will never get two songs buffered in advance by default in foobar2000 unless they are shorter than the 30 second output buffer. Only track that is being decoded or about to be decoded is affected by any buffering settings.

You should never hear a glitch with default settings. If you do, you should check DPC latencies. There can be many causes of unwanted delays that ruin realtime playback, some power saving settings combined with bad drivers can make things worse. You can also try disabling Windows dynamic tick.