More > JRiver Media Center 23 for Windows
MC doesn't behave nicely doing resource intensive tasks
steff:
--- Quote from: RoderickGI on February 01, 2018, 04:03:09 pm ---Steff do you get stuttering of the audio when a second file is being loaded and the MC interface becomes unresponsive? I didn't get any stuttering in my tests.
--- End quote ---
As I explained, YES... while the old file is being played and the new one is being loaded from memory, network is used up to 100%, the audio played is terrible.
The workaroud I found is to force the WLAN adapter from 802.11ac down to 802.11n or... even better... down to 802.11g
In this case I do not see huge network spikes... I do not see DPC latency spikes and audio is fine.
if we de-couple the playing activity from the network activity.. of course I do not have any problems at all... I can leave the WLAN adapter to its default 802.11ac... and with such high speed is a matter of few seconds.
dtc:
With Loading Full Album (Not decoded), it can sometimes takes a while to load. That is why Matt added a Loading Files message if the load is going to take very long. And, yes, the UI is unresponsive during that time. But I am OK with that. I am, after all, loading up a full album with the idea that I am going to play the whole thing. A little wait is OK and there is not much MC can do about the speed of the network and/or drives. Would it be better to have the UI immediately respond. Sure. But is it generally not a big deal. As I said, I am about to play 40 minutes or more of music. I can wait 20 seconds for loading. And, the Loading Files message tells me what is about to happen. If the loading is taking several minutes, then it can become an issue. But the only time I have long waits is on very large albums, like 5+ GB DSD albums.
When playing a full album from memory, if I select a new album to play, playback continues until the new album is loaded. That is OK with me, as I would rather listen to the music than have silence while waiting. I do not have any glitches during the transition. If I want silence during the transition, I can always hit stop before selecting the new track. I know steff does not like that idea, but it works for me. It gives me the flexibility I want and is not much effort.
With Loading Full File (Not decoded) with 23.0.96, when I select a new track the loading is usually quite fast and the UI seems to stay responsive through that transition. The playback does not stop immediately, but it certainly stops before the second file is fully loaded. The fact that music plays part of the time while the second track is loading is not an issue.
My primary use of memory playback is to avoid occasional glitches when loading large files from external disks (not NAS) on a slow computer. The current implementation does a wonderful job of avoiding startup glitches that can occur without memory playback. With my slow playback machine (JMark of something like 450) full album loads can be somewhat slow, but that is my fault for having such a slow machine with a usb 2 external drive. I am somewhat proud of being able to play 5+GB DSD files on what may be the slowest computer in the JRiver family. But I did upgrade it to a full 2 MB of memory!
Bottom line - I am very content with the current implementation (with .96) of memory playback. Yes, it could be improved by having the UI responsive during loading of full albums, but that is a very minor issue for me. It does not start the music any faster.
RoderickGI:
--- Quote from: steff on February 01, 2018, 05:28:50 pm ---As I explained, YES.
--- End quote ---
My apologies. I didn't think through all the implications of these statements:
--- Quote from: steff on February 01, 2018, 10:22:11 am ---Having lower network burst ... the spike in the latency is much lower and so... less frequent audio dropouts.
At the of the story, forcing 802.11g will lower much more the network burst and there is no more latency spikes and no more audio dropouts at all!!!
--- End quote ---
Obviously if you have dropouts except when using 802.11g, then you have stuttering when using the faster network. Strange, given that the first file is still in memory and being played back. I would expect to see a CPU spike when you get a dropout, since playing the first file doesn't need network activity. But if the one thread is handling both the file retrieval and playback, I guess just switching tasks would cause a glitch.
That is all good information for JRiver to consider.
While the cause does appear to be the threading design of MC, I was wondering if some network change might alleviate the problem of stuttering. I tested on an ethernet connection and saw no stuttering. I would have to do some extra setup work to test over wireless, and I only have up to 802.11n to test anyway.
So are there any network engineers around here who could suggest Network Adapter settings changes that might prevent the file load over a wireless network from interfering with playback? A priority change perhaps? I was thinking Quality of Service type settings, maybe? Particularly if they would be implemented specifically to MC, so the general network speed could remain high (802.11ac), but the actual throughput could be throttled enough to allow the MC thread to play without stuttering. Maybe smaller bits of data over the network would do that? Turn off/on Jumbo Frames? Turn off large send Offload? Guessing here.
JimH:
Have you thoroughly explored the possibility that antivirus software is stepping in and causing problems? Here are some examples: https://yabb.jriver.com/interact/index.php?topic=86096.msg588759#msg588759
On Win10, there have been more than a few problems reported recently even with Windows Defender
JimH:
--- Quote from: RoderickGI on February 01, 2018, 06:23:55 pm ---While the cause does appear to be the threading design of MC ...
--- End quote ---
It's possible, but I don't think you could conclude that yet.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version