Print

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

[Don W]

When I play an album, the progress bar displayed in MC gets progressively more and more out of sync with the actual device output. By the time that last track starts playing, the MC progress bar is up to 25 seconds or more ahead of the music that is playing. What I can see is the MC progress bar and now playing display text changes to next track long before the previous track has actually ended. This is definitely not attributable to fade in/out.

A strange side effect is that the last song of most every album is truncated abruptly several seconds before its true ending. This is what led me to investigate and discover the progress bar being out of sync.

It is device dependent. It happens with the USB converter that's built-in to my amp, but it doesn't happen with an old USB converter I have laying around. It doesn't matter if I use ASIO, WASAPI or Kernel Streaming. It doesn't happen when using the DIRAC audio processor - a software based device, like WDM. The DIRAC audio processor is setup to output to the same USB device which is giving MC problems. This is probably why I haven't noticed until now, because I'm usually using DIRAC.

I have "Use gapless for sequential album tracks" checked. It doesn't happen if I uncheck that. It doesn't matter whether I load or play files to memory or whether I use SoX resampling.

Any ideas?

I've tried MC versions 22.0.32 and 22.0.28 - it happens on both.

Windows 10.

[AndrewFG]

I think I recall that there was another post on the same or similar subject within the last month or so. You may want to try searching the forums here..

[Don W]

I can't find any posts that seem to be related  ?

[Don W]

Bump.

[Don W]

Is there no one from JRiver with insight into what could be going on here? Is it a bug in the USB converter's device driver? If so, I am in contact with the manufacturer, and could pass along any insights gleaned here. I do have the latest version and it is said to support Windows 10.

[Don W]

I just discovered that this is an issue with the SoX resampler, or so it would seem. I had tested it with SoX disabled before my first post, or so I thought, but there must have been something wrong with my test method. I haven't tried with SoX enabled using a different USB converter but its a good bet that it would have the same problem. Also, contrary to what I said in the first post, it doesn't matter whether or not I'm using the Dirac audio processor. It seems to happen when SoX is enabled and using gapless playback. I am upsampling from 44.1 to 48 because the DSP unit I am using for my active crossover operates at 48.

[Hendrik]

There have been other reports of SoX being related to this before, but your original post said SoX didn't change anything so I discarded that possibility.

Unfortunately we were unable to reproduce this issue so far, nevermind come up with a plausible explanation of what's going on. So right now the only thing we can recommend is not to use SoX if you suffer from this - it's marked as experimental for now still for a reason.

[AndrewFG]

Unfortunately we were unable to reproduce this issue so far, nevermind come up with a plausible explanation of what's going on.

I guess that this is a buffering and/or flow control issue between the MC regular streamer, the Sox engine, and the USB port, plus any asynchronous buffer filling and emptying threads between them.

When pushing a bit stream to USB, I suppose that you measure the "position" according to how many bytes have been pushed to the USB port? I suppose that the SOX engine has an internal buffering scheme so that it can potentially consume incoming bytes faster than it needs to write to output. So when pushing a bit stream to via SOX to USB, my question would be whether you measure the "position" according to how many bytes have been pushed to the SOX engine, or according to how many bytes have been pushed from the Sox engine output to the USB port?

( PS I don't know much about the various (WASAPI, ASIO, DirectSound) audio driver APIs, but obviously rather than just measuring how many bytes one has pushed to them, it would be better if they have an API function where you can interrogate how many bytes (resp. seconds) they have actually played out; but perhaps that is not available ?? )

[Hendrik]

We only use the SoX Resampling library, there is no "SoX Engine" (two entirely different things). The audio input/output behavior of a resampler can be tested and verified rather easily.

[AndrewFG]

Please don't bite me; I am only trying to help..

I assume that you pass a block of music samples into the resampler code, and (some time later) you get back a larger or smaller block of new samples (depending on whether you are up- or down- sampling). I assume that the passing of input blocks in, and output blocks out, cannot be fully synchronous, because the output resampling process has to process several input samples in order to generate each output sample, and so it has to hold (a copy of) some of the input samples from the end of one block, to be used in combination with the input samples at the start of the next block, in order to generate a smooth output sample waveform across those two blocks. Or??

So you either have a "stuttered" synchronous I/O across the resampler code, or an asynchronous I/O process. So I would still look at whether you measure "position" based on the count of samples/blocks passed in, or whether you measure it based on the count of samples/blocks passed out...

PS the behaviour may also differ depending on whether you are up or down sampling, and the numeric ratio between the in and out sample rates. Since depending on those parameters, the resampler may need to process over more or fewer input samples to generate a respective output sample.

PPS you may also find that the number of samples in the output block per sample in the input block may not be a constant multiplier. Depending on whether or not the resampler code has currently enough input samples to generate the respective output sample. In other words, in your position code, do not count just the blocks, but rather count the actual number samples in each block..