Print

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

[wer]

I discovered this by accident while taking a quick look at a large number of tracks, so it might be low-incidence with normal behavior, but it's a glitch that shouldn't be there. I had switched my track change method to cross-fade (aggressive/smooth doesn't matter) to eliminate a small click during track changes. Not sure if the click is a MC or DAC problem, but cross-fade 0.1s eliminates the click.

I found that if your track change/switch tracks method is Cross-Fade (0.1s) then switching tracks frequently can cause MC to go into "Buffering" mode and it hangs playback for 10-15 seconds. By frequently, I mean 10-30 manual track changes per minute.  It is especially easy to provoke if you manually change tracks to the previous track, within a second or two of the next track starting.

I can NEVER provoke this behavior when the track change method is gapless, only cross-fade.

This behavior also occurs during normal use, most frequently if you jump to the previous track right as the next track starts playing, even if you have done no manual track changes recently. Again, this only happens when cross-fade is used. Gapless never exhibits the issue. (but for me, gapless has a click)

It's an annoying issue because MC hangs on "Buffering" for so long. It eventually recovers and the correct track plays, but the first second or two of the track is cut off.  Normally I would associate "buffering" with a delay reading the media file from disk. But if that were the cause, switching from crossfade to gapless wouldn't fix it.

[JimH]

Please report a probable bug in the thread that announced the build.   Make sure it also occurs in the most recent build.  Link to an external thread if it may involve discussion.  Thanks.

[Neco]

I don't think this is specific to v27

I'm on 26.0.107 (64-bit)  and this has been driving me nuts.  I am guessing a windows 10 update broke something.

I also use crossfade  (aggressive) -0.2s  on manual track changes due to DAC pops.   Sequential track changes are set to seamless but I rarely listen to anything long enough to see if it happens there.

Sorry if this belongs somewhere else,  this is the first relevant thread that popped up

[JimH]

DAC pops might be avoidable.  Try using MC's DSP Studio > Output Settings to force everything to the same bitrate and sample rate.

Double check Windows Defender configuration.

[wer]

DAC pops might be avoidable.  Try using MC's DSP Studio > Output Settings to force everything to the same bitrate and sample rate.

Double check Windows Defender configuration.

That's not the problem. It happens when everything is the same bitdepth and sample rate, and it happens without Defender.

[Neco]

Agreed,  my settings have been the same for months.  The buffering issue is recent -  I don't know how recent because sometimes I just update the program without thinking of checking stuff.

Prior to that working fine tho.    I brought up the issue of Pops and such before and was told it was the drivers/manufacturers fault.   But that's really not what this thread is about....

I have Windows audio set to 16bit 48Khz,   Output format in MC converts everything to 48Khz, Stereo.  No output encoding, etc.
Windows -was- set to 24bit 48khz but switching from that made no difference.   This happens under ASIO and WASAPI.   Haven't tested other modes yet.

I might try reverting when I have some free time to experiment and see if I can find a build where it changed.

[wer]

It wasn't introduced in MC27. The problem is present in MC26.

[Matt]

We haven't seen this, so it's a riddle.  Does adjusting prebuffering in Options > Audio change anything?  Thanks.

[wer]

Matt,

I had my prebuffering set to 6s, the recommended/default amount.

I tried changing to 2s, and that did not help.

So I tried changing to 20s.  That significantly reduced the occurrence of the "buffering" issue. It was harder to make it happen. When it did happen, the stall was just as long.

With 10 seconds, there was a small improvement in terms of reducing the frequency of the problem, but it was still not that difficult to make it stall.

Changing prebuffering had no effect on DAC clicks, which is the provocation for trying cross-fade in the first place.

Thanks...

[comox]

This buffering problem has also been bothering me for many months. I can't remember when it started.

I tried all the memory playback and prebuffering settings without success.

I'll try gapless instead of crossfade track changes as you suggest wer.

[wer]

Matt, I spoke too soon. Increasing the pre-buffering from 6 to 20 doesn't make it harder to produce the buffering problem, it just moves it.

With prebuffering=6, going forward or backwards (esp backwards) 1 track can cause the problem.

With prebuffering=20, it very rarely happens going backwards or forwards 1 track, but instead it's very easy to provoke the "buffering" condition when going forward or backwards TWO tracks.  Ctrl-N + Ctrl-N = Buffering.

Again, this never happens when using gapless track changes. (but gapless manual track changes produce a click. Gapless normal progression for sequential album tracks do not produce a click: gapless works perfectly in that context. It's only manual track changes with gapless that produce the click)

[Matt]

With resampling enabled I was able to reproduce some slow-downs.

I've got a change going into the next build:
Changed: When changing tracks manually, the flush done is lighter preventing lags buffering.

Thanks for the help

[wer]

Thanks, I'll check it out.