INTERACT FORUM
More => Old Versions => JRiver Media Center 26 for Windows => Topic started by: Jamil on June 08, 2020, 07:59:56 pm
-
I am playing a FLAC file under version 26.0.90. Below is the audio path:
(https://dl.dropboxusercontent.com/s/jmgq470lvyrlzmy/mc26_audio_path.png)
As shown above, the decoded file is 100% in memory.
I am noticing that when I click the seek bar to change to a new position for playback, there is a long delay before the position change occurs. Why would this be happening, since the entire file is in memory? The delay is over one second. Buffering for my DAC is set to the default of 100 milliseconds.
-
Also, seek is set to Gapless in options.
-
It could be that it is your DAC that takes a while to implement the seek MC requests.
What sort of DAC is it? If a USB or Network DAC, Wireshark can monitor either, and will show you if MC issues the seek command quickly, or not.
-
It's a USB DAC that other media players do not share this latency that MC26 does.
The delay in MC26 is similar to slow APE seeks that I would not expect in FLAC.
-
APE files don't have any special slow seek. They're no different than FLAC in that regard.
What you describe could be a buffer setting that's too big.
If your DAC is directly connected, what are the audio settings?
Try Direct Sound.
Are you using the 64 bit version of MC?
-
Yes -- 64-bit. WASAPI exclusive is my connection.
I have tried bunches of other free players that all use WASAPI exclusive to not experience this latency when seeking. The distance in seeking influences the latency. Where I am confused is that this is all in memory and should be fast. I can understand if the data under seek was on slow storage, but it is not.
My buffer size is the default of 100 milliseconds. I can try lowering this, but based on the behavior I am seeing this is not the cause.
-
Can't reproduce this, seeking with gapless is near-instant using the same settings as above.
-
Try not using memory playback.
Try Direct Sound.
-
I still have logging enabled that is probably slowing things down. I will turn it off now.
-
I turned off memory playback and then tried again. Seeking is not instant and there is still a delay.
I switched to DirectSound instead of my DAC. Seeking is not instant and there is still a delay.
-
Try playing to a different device.
-
DirectSound defaults to my SoundBlaster device that is different.
I will try motherboard audio (if it is still enabled).
-
Motherboard audio is instant.
The latency appears to be related to USB.
-
Does the Soundblaster have the same problem?
-
Does the Soundblaster have the same problem?
Yes.
-
You might try changing USB ports. If you're using a USB 2.0 port and you have a USB 3.0 port available, you might try using that one instead.
-
I have no free ports available, so I would have to swap ports.
Considering that two different devices in two different ports share this same issue, I am not overly confident that the behavior will change. My workstation has lots of ports in the back, and I am not using any hubs.
-
I have no free ports available, so I would have to swap ports.
Actually, if you're using all USB ports there's also a good chance the USB controller(s) are "saturated" from having all USB ports used, which also *could* cause an issue like this.
-
As previously stated, this happens under MC26 and not other free players I have tried. That seems doubtful.
-
I turned off memory playback and then tried again. Seeking is not instant and there is still a delay.
I switched to DirectSound instead of my DAC. Seeking is not instant and there is still a delay.
-
Could you test another file type other than FLAC? I'm wondering if the issue is in the plugin, or the playback chain.
Thanks.
-
I just tested an OGG file. The issue is improved. Seeking is not instant, but it is much better than before.
-
Could you share one of the FLAC files with me? I'm matt at jriver. Maybe it will show something.
Thanks.
-
I am sending an example file now, but I do not believe the issue is related to a specific file. There is a delay of 1 to 1.5 seconds with all seeks for all files played on all USB audio devices on my system.
-
Thanks for the file. I get instant seeks with it.
Try setting Options > Audio > Stop, Seek & Skip > Seek
Do any of the settings help?
-
This is the current setting:
(https://dl.dropboxusercontent.com/s/msnb6w8yh7iy2cf/mc26_stopseekskip.png)
I will try the different options to see if it changed behavior. I avoid all fading options and intentionally turn them all off.
-
I closed MC26 then restarted it. It has actually improved after a restart. The latency is now much less. It is not instant, but it shows an improvement. I wonder if it gets worse the longer it runs? I usually play it nonstop for twenty four hours, and I never reboot either.
-
I switched to DirectSound instead of my DAC.
DirectSound defaults to my SoundBlaster device that is different.
These two statements worry me, as they are not congruent with the way Direct Sound is selected in MC. Perhaps this indicates a misunderstanding of MC, or is just a language issue.
In MC you select a Zone. For that Zone you selected an Audio Device. MC presents all the Audio Devices that Windows tells it about, and they are the combination of the physical sound device and the audio protocol to be use; ASIO, WASAPI, or Direct Sound.
So you wouldn't "Switch to Direct Sound instead of your DAC" and Direct Sound shouldn't default to your SoundBlaster.
Does your DAC not support Direct Sound? If it does, try the DAC with Direct Sound.
I will try motherboard audio (if it is still enabled).
Motherboard audio is instant.
The latency appears to be related to USB.
I closed MC26 then restarted it. It has actually improved after a restart.
Sounds like it could be a USB issue, but it could also be the audio drivers;
It could be that it is your DAC that takes a while to implement the seek MC requests.
What sort of DAC is it? If a USB or Network DAC, Wireshark can monitor either, and will show you if MC issues the seek command quickly, or not.
If you have latency on the SoundBlaster and the DAC, that would point more to a USB issue. But the improvement after restarting MC points a little more toward drivers.
-
These two statements worry me, as they are not congruent with the way Direct Sound is selected in MC. Perhaps this indicates a misunderstanding of MC, or is just a language issue.
In MC you select a Zone. For that Zone you selected an Audio Device. MC presents all the Audio Devices that Windows tells it about, and they are the combination of the physical sound device and the audio protocol to be use; ASIO, WASAPI, or Direct Sound.
So you wouldn't "Switch to Direct Sound instead of your DAC" and Direct Sound shouldn't default to your SoundBlaster.
Does your DAC not support Direct Sound? If it does, try the DAC with Direct Sound.
Sounds like it could be a USB issue, but it could also be the audio drivers;
If you have latency on the SoundBlaster and the DAC, that would point more to a USB issue. But the improvement after restarting MC points a little more toward drivers.
With my current hardware, Foobar2000 seeks instantly. There is no latency or delay. The only software I experience this issue with is MediaCenter.
Maybe showing you screenshots helps confirm what I stated:
https://dl.dropboxusercontent.com/s/6kp34ay1lyf1jch/mc26_directsound.png
See how the device clearly shows DirectSound above? The Default device is my USB SoundBlaster.
-
You have selected the default Windows audio device, which is called "Default Audio Device [Direct Sound]" because the default device in Windows, your USB SoundBlaster, is set to Direct Sound.
It is not Best Practice to select the Windows default audio device in MC. In fact, I think it is bad practice, because whenever you change the Windows default audio device, you are also changing the audio device that MC plays to, which could mean that the settings you are using aren't a good match to the device MC is playing to.
If you wish to play to your USB SoundBlaster using Direct Sound, select that option as the Audio Device in MC. It will probably be called "USB SoundBlaster [Direct Sound]" or similar.
I don't know why you experience latency when using MC, but the language you used to describe your setup, and the fact that you have selected the "Default Audio Device [Direct Sound]" in MC rather than "USB SoundBlaster [Direct Sound]" shows that you do not have a full understanding of how audio works in MC, and possibly how audio works in Windows. This is not a criticism. It is an observation.
Also, I don't work for JRiver, so I'm not trying to move "blame" away from it. What I, and others here, are trying to understand is how you have MC set up and hence why you observe latency. It could be a MC software issue, or it could be a misconfiguration. Awesome Donkey and Matt can't reproduce the problem, so whatever it is, it is probably something to do with your environment or setup. It could be the USB on your motherboard. Typically a motherboard will provide some USB ports directly from the chipset, and some from a third party chip. Often those two sources of USB ports have different performance characteristics. So it could be that the ports you have the USB DAC and USB SoundBlaster plugged into do have some latency, or that the driver does when using those ports, particularly if they use a different driver to the Microsoft supplied one. It could be something else.
Post a screenshot like the image I have attached, showing all the available audio devices, both in the first group and the "More" group.
Also, when you were playing to your USB DAC you said you were using WASAPI. Please confirm which audio device from the list above you had selected. Also, as Foobar2000 seeks instantly, which audio device is it playing to?
-
Sure. I will post more screenshots.
First, I will post from Foobar2000 that works with almost zero latency as fast at seeking as MC26 was with my motherboard audio:
(https://dl.dropboxusercontent.com/s/2xqb6i70p2yer2k/foobar_output.png)
https://dl.dropboxusercontent.com/s/9d1vsyc1illbq94/foobar_fast_seeks.png
See my mouse cursor above in that screenshot? I clicked various portions of the currently playing song with Foobar2000 switching with nearly instant response from the music playing from my DAC. There was no delay, and it was very responsive. Perfect. I am showing this first, because this is how it should be done. Foobar2000 is using the same hardware with the same drivers. There should be no excuses, and it is 100% possible if implemented correctly.
Here is the screenshot you requested:
https://dl.dropboxusercontent.com/s/5k34zu4qpstbjjz/mc26_audio_latency.png
When I play this exact same file that Foobar2000 handled perfectly, MC26 has a seek delay of at least one second. The more often I seek, the worse it gets. This appears to be an obvious bug in code. I am glad that you acknowledge this possibility at least.
-
I have no free ports available, so I would have to swap ports.
Unplug everything you can, just to test.
Test playing a local file.
-
Can anyone else reproduce this problem?
-
I am working my day job right now and not able to help test.
I can when my day ends.
-
Can anyone else reproduce this problem?
No. I changed all my settings to match Jamil's. MC seeks instantly.
But I tested on my Workstation, which uses motherboard audio.
-
Unplug everything you can, just to test.
Test playing a local file.
I ran a couple of tests--
I unplugged absolutely everything that I could USB plugged into my workstation. The only device that I now have plugged in is my mouse. I cannot find my PS/2 mouse to use instead. Additionally, I plugged my DAC into the rear USB3 socket as per a suggestion made above. I rebooted Windows 10 Pro.
I changed Seek from Gapless to Standard.
I reproduced the seek latency after reboot with 64-bit MC26 playing right now (version 26.0.90).
Also, prior to unplugging everything, I installed the x86 version of MC26 on my workstation with the 64-bit version still installed. I reproduced the latency with the 32-bit version too. Foobar2000 is 32-bit, so I attempted to even the playing field. The seek latency exists on both the 64-bit and 32-bit versions.
-
On both of my systems clicking on the seek bar to a new position is instantly responded to, there is no latency.
-
A couple more notes here:
MC26 has been running for a very long time playing music nonstop on my system. While the current song was playing, I clicked the seek bar to near the beginning of the track. It showed "Buffering" at the top for quite a number of seconds prior to doing anything. It then resumed music playback after moving playback to the correct position.
There's an issue here for sure, and I see strange behavior after long runtime continuously playing.
-
If that is repeatable and you can catch that Buffering message in a log file, JRiver may be able to see what is going on.
Just make sure you reset the log shortly, but not immediately, before trying the seek test, so that the log file isn't huge.