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: A way to fix gapless/buffering issues under some "extreme" circumstances. (Read 1612 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

A way to fix gapless/buffering issues under some "extreme" circumstances.

As I understand, you can change the look ahead buffer that the player decodes before actually playing anything, which helps preventing jerky playback and helps with the gapless feature. Pretty standard stuff. But, a problem I've been experiencing under certain circumstances has made me aware, by inference, that there's also the aspect of "how soon to start buffering in the next track"

Some "exotic" formats (videogame emulated stuff, mainly) can have have some rather intensive track initialization overhead, and I'm not even counting how intensive the actual decoding of the audio may be, or the added overhead of using DSPs that demand large buffers,
Even removing all DSPs and experimenting with bigger and smaller buffer sizes, a problem remains where, even if playback is fine after it gets going, I think foobar waits too long, too close to the end of the track, before it starts to buffer the next track.
Because of that, the buffer doesn't fill up on time and foobar pauses playback of the current track, waiting for the buffer of the next one to fill up. Then, it resumes playing the last second or so of the current track and transitions into the next. There's no gap between tracks, but it creates a new gap at the tail of the current one.
This also happens some times when playing files from an external mechanical drive that insists on going to idle mode after just a minute or two and then takes about 8 seconds to spin up again.

I think this could be fixed in one or two non mutually exclusive ways:
In the one hand, a way to adjust how early the player starts pre-buffering the next track. I will probably try 10 seconds, or so, before the end, maybe more to cover the posibility of a combination of slow to spin up storage and big overhead initializtion format.
On the other, a setting to tell the player not to stop the current track even if the buffer for the next isn't full yet, so that the inevitable gap happens at the actual end of the track, instead of creating a gap at the tail of the current one.

Thinking about it, it may also help with direct playback from archives setting the prebuffering early enough, especially if the archive is solid... not that I would do that with regular compressed audio codecs, which don't benefit at all from further compression attempts, anyway, but there are other scenarios...

Re: A way to fix gapless/buffering issues under some "extreme" circumstances.

Reply #1 –
What formats exactly? Did you try maximal buffer size ( 30000 ms) ?

Re: A way to fix gapless/buffering issues under some "extreme" circumstances.

Reply #2 –
Quote from: radorn on
I think foobar waits too long, too close to the end of the track, before it starts to buffer the next track
It doesn't wait anything. If you set buffer size 10 s it will begin to decode next track when 10 s are remaining to the end of current track; if you set buffer size 30 s it will begin to decode next track when 30 s are remaining to the end of current track.
Also, in 1.4 there was additional option introduced in advanced preferences - Advanced->Playback->Buffering->Read ahead for local files (kB).

Re: A way to fix gapless/buffering issues under some "extreme" circumstances.

Reply #3 –
Quote from: Rollin on
What formats exactly?
Mainly emulated videogame formats. Mot "mere" chiptunes, where it's usually a sound generator being emulated and fed data, but formats that require the CPU, RAM, etc of the system to be emulated too. More precisely, I'm talking about, the PSF derivatives (PSF1, PSF2, USF, DSF, GSF, 2SF...), but others may be affected too. It's my understanding that these need some intensive initialization before they start spitting out any audio. It's not just buffering in some data and start decoding.
These are often very small in size, so I don't think increasing the read ahead in terms of file size will help. That seems more geared to deal with slow storage media and it won't help here.
If I had to make a crude analogy, I'd say that these formats are more like MIDI, but you need to emulate some particular synthesizer hardware along with it too to run custom code for the synth and data that comes with the midi file.

I think that, last time, I tried decreasing the buffer size to improve track start times. Your suggestion of increasing the buffer size actually seems to improve the track-end transitions, but it also gets me poorer cold-start times for all formats, which is annoying when skipping or doing anything other than just playing full tracks through a list in order.

Usually I set my buffer to 2000ms. 30000ms certainly fixed the gapping problem, but with the game I'm testing just 3000 also seems to do the trick. EDIT: It really depends on the track that comes next. I opened the console, I see the next track being loaded, and a little after the track is paused for half a second or so before resuming just before it ends.

Since I think the problem is caused by the initialization overhead of these formats, increasing the buffer size doesn't seem to be the optimal solution. It makes cold-start and skipping more intensive and may incurr delays for all formats (even if for many it may be barely noticeable). Also, a buffer size that may solve the issue in one case may not be enough for another, as these formats are based on ripping audio engines and music data from games and emulating them as a playback method, so each one can behave differently and be more or less intensive.

That's why I think it'd be best if you could just set how early to start decoding the next track independently of buffer size. And, for when not even that is enough, shift the pause to the actual gap between tracks, instead of pausing the tail of the current track.