Print

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

[Bobaudio]

I currently am running JRiver V19 on a Computer Audiophile CAP server 3.0 design (Intel atom with 4 gig of memory). When I play .dsf files (200 megabytes in size via a Windows Media Server / NAS on a wireless N network) the playback all too frequently stutters two to three times during the typical four minute track for about 5-7 seconds each time. This happens even with the “play files from memory instead of disk” options set within JRiver. Windows Performance Monitoring analysis reveals that there doesn't seem to be much buffering if any occurring at the beginning of the track like I would expect there should given the “play from memory …”option has been set. Instead there are bursts of network activity three to four times during the playback with the first burst at the start of the track. The network traffic lasts for 30 seconds or so averaging about 12 megabits/sec. This happens two to three times during the song. Just at the start of the second and third traffic bursts the stuttering occurs suggesting the JRiver buffer is empty and the NAS file and transfer read can't respond fast enough thus starving the playback momentarily.

It seems two things are happening that I can't explain as follows:

1)   Why isn't JRiver reading the entire file into memory before the song starts
2)   Why am I getting any network traffic of significance during the playback
3)   Why am I getting any stuttering especially associated with the leading edge of the network traffic “calls”

Can anyone explain this behavior? I appreciate any help you might have to give.

PS: With simple transfers my network performance is nothing less than 100 megabytes/sec.

[6233638]

The Memory Playback option is broken in MC19.
Rather than eliminating the possibility for playback interruption, it actually makes playback more susceptible to interruption.
 
There were also changes made to DSD playback which, combined with the new Memory Playback system in MC19, actually cause Media Center to interrupt the playback itself.
Something is seriously wrong when limiting Media Center to a single CPU core on my system actually results in smoother playback than allowing it to use all four.

I have been complaining about these issues as soon as the changes were made, but they have largely been ignored.
It took four months to fix a buffering problem where DSD playback would skip with the Memory Playback option enabled: http://yabb.JRiver.com/interact/index.php?topic=85733.msg586412#msg586412

I posted a topic about these problems in the MC20 Windows forum, proposing solutions to fix the Memory Playback situation, but it has been relegated to the PC hardware section now, since Jim thinks it's a problem with my PC and not MC. http://yabb.JRiver.com/interact/index.php?topic=90665.0

1)   Why isn't JRiver reading the entire file into memory before the song starts
2)   Why am I getting any network traffic of significance during the playback
3)   Why am I getting any stuttering especially associated with the leading edge of the network traffic “calls”

In MC18, Memory Playback loaded the file into memory as soon as playback started.
It then decoded to a ~50MB buffer for playback. This meant that your 200MB DSD file was stored completely in RAM, and there was a constant low-level of CPU usage as it tried to keep the 50MB buffer of decoded audio full.

In MC19 the file is no longer cached. Instead, they try to store up to 1GB of decoded audio in the buffer. With DSD files, that's not enough to store the entire track.
Trying to decode 1GB of audio as quickly as possible results in spikes of very high CPU usage at the beginning of playback, or any time the buffer is being filled.
Quite a few users have reported that the last ~20 seconds of a track will stutter when Memory Playback is enabled, as that is when it tries to fill up the buffer again with the next track.
 
With DSD files, which often do not fit into the 1GB buffer when decompressed, you get these big spikes of CPU activity every 30 seconds or so, as the buffer is emptied and has to be refilled as quickly as possible. (yes, the buffering basically works as: fill the buffer as quickly as possible, empty it out, and fill it again as quickly as possible, rather than being a continuous stream of activity)
Since the file is no longer cached in memory, every time it has to fill the buffer again you also get these spikes of network traffic or disk activity in addition to the high CPU usage.
 
So in essence, the memory playback can actually cause interruption, because of its own CPU activity, or allow playback to be interrupted in the middle of a track if there is high disk activity or network access, and MC can't access the file quickly enough.

[JimH]

I currently am running JRiver V19 on a Computer Audiophile CAP server 3.0 design (Intel atom with 4 gig of memory). When I play .dsf files (200 megabytes in size via a Windows Media Server / NAS on a wireless N network) the playback all too frequently stutters two to three times during the typical four minute track for about 5-7 seconds each time.

That may just be a bandwidth limitation.

You might learn something by testing with a cable.

[Bobaudio]

6233638,
Thanks for your response. What you stated makes perfect sense and is exactly what I'm seeing. Thanks for the quick response.

JimH,
I hard wired my JRiver dedicated PC to my router. My NAS is connected to my router as well. Although the file transfer rate was slightly higher, the network traffic pattern showed about the same as when wireless. I can't say the slight bandwidth improvement has been enough to fix the stuttering issues I have been experience 100% of the time. It seems to me the application should not be that "sensitive" to files that aren't especially  large by today's standards. My next step is to try running JRiver in "don't run from memory mode" which I understand doesn't really work anyway. If that approach doesn't pan out I man have to consider alternative apps. Thanks for the input.   

[Matt]

Increase buffering in Options > Audio > Device settings...

[Matt]

The Memory Playback option is broken in MC19.
Rather than eliminating the possibility for playback interruption, it actually makes playback more susceptible to interruption.

You've got a real ax to grind.  That's just not true.

[6233638]

You've got a real ax to grind.  That's just not true.

It is absolutely true, and I have repeatedly posted evidence of this.
Enabling Memory Playback in MC18 had little-to-no effect on CPU usage, and made playback far less susceptible to interruption, since the file was stored in RAM.
 
In MC19 enabling Memory Playback can introduce significant CPU activity every time that the buffer is refilled, and many tracks are now only partially stored in memory since, uncompressed, they do not fit into the 1GB buffer.
This makes playback highly susceptible to interruption in the middle of a track due to slow disk/network access, or high CPU activity.
 
There are even users who have experienced playback interruption caused by the increased CPU usage that the Memory Playback changes in MC19 introduced, and the only solution for them has been to disable it.


In MC18 playback could only be interrupted by slow disk/network access when changing tracks, never in the middle of playback.
The changes to Memory Playback that I have proposed would not only restore MC18's robustness during playback, but make it even less susceptible to slow I/O by caching more than just the currently playing track.
Rather than only allowing ~20 seconds to cache the next track, caching the current track and the next two (or perhaps the current track and as many tracks fill ~10 minutes of audio) should leave more than enough time to almost eliminate the possibility of slow I/O interrupting playback.
In most cases this should use less RAM than the current system as well, since it would be caching files rather than decompressed audio.


Since the changes made in MC19, I have been unable to leave Memory Playback enabled:
1. For the first four months, SACD playback would drop a portion of the audio when the buffer was refilled.
2. Because I cannot run anything else on my computer without the increased CPU usage interfering.

It interferes with basic tasks such as scrolling a webpage, and makes it impossible to run demanding tasks without causing interference.
 
With demanding tracks such as multichannel SACD playback, things can get so bad that it even manages to interfere with the mouse cursor.
Reverting to MC18, or limiting Media Center to a single CPU core prevents this from happening—so it isn't that my PC can't handle multichannel playback, it's that the way MC handles it causes problems.
 
 
Since the official JRiver stance on Memory Playback is that it does not affect sound quality—which is something that I agree with—it should be designed to make playback as robust as possible.
 
 
On a high-end development machine where testing may be done with fast disk/network access with MC being the only task running, perhaps the new Memory Playback system appears to be working well.
But on slower systems, or times when other applications are tying up the disk/network (even things like Analyzing Audio in MC while playing music can do it) it is better to disable Memory Playback rather than leaving it enabled.
 
Memory Playback should be increasing the robustness of playback at the cost of using more RAM.
Right now it just eats a gig of RAM for no apparent reason.

[AndrewFG]

Did anyone answer my question whether MC's memory playback relies on very large atomic SSE memory move instructions. These might be hard for the OS to interrupt especially on single core CPUs..

[Hendrik]

Did anyone answer my question whether MC's memory playback relies on very large atomic SSE memory move instructions. These might be hard for the OS to interrupt especially on single core CPUs..

Any memory copying operation is automatically using those, because its much more efficient.
However, no single instruction can be interrupted, and the singular instructions don't take that long.

[AndrewFG]

Thanks for the info. I don't really know enough about the internal Intel CPU instruction sets, but I know that SSE is optimised for fast repetitive pipelined memory moves, so I was guessing that they might be harder for the OS to interrupt.

[JimH]

Are you using antivirus software.  If so, uninstall (to test).  Disabling isn't always enough.  You could read about some of the problems they cause in this thread:

http://yabb.jriver.com/interact/index.php?topic=86096.msg588759#msg588759

[mwmccaw]

I, too have been experiencing lots of stuttering during playback since installing MC19, which I never saw before.
I have been using play from memory, with latency and buffering set to 500 ms, but whenever I scroll the selection in Media Center (i.e. to pick the next track to be played), playback starts stuttering badly.
I'll try turning off memory play, but I have to agree - it is broken in MC19, and was not in earlier versions.
Mike

[6233638]

Please report back about whether or not disabling the option helps.
You may wish to return to your previous buffer size - some devices don't like 500ms.

[mwmccaw]

Disabling play from memory helped - a bit.
I had increased the buffer size gradually to max without any effect.

It now takes longer to stutter when scrolling, but it still does.
It appears that my problem is that scrolling through the lists takes priority over playback!
I should mention that I'm playing over a gigabit network from a Synology diskstation, so both scrolling and playback generate network events.
Is there some way to give playback absolute priority?  If there is, I'd like to give it a try.

[mwmccaw]

Actually, I should make a couple of corrections to what I've posted:

1) the problem really appeared after downloading the latest MC19 update.  I was running 19 before without the issue.

2) the library is local, but the files are on the diskstation, so scrolling through the track lists should NOT generate a network event.

But the problem remains the same - when scrolling, playback is momentarily halted repeatedly, leading to highly audible stutter.
I haven't tried doing other things to see if they cause, stutter, because the computer is dedicated to audio playback.

[greyleopard]

I started having these problems with MC-19 as well.  My HTPC is dedicated to JRiver Media center and it is chewing up both my CPU cores.  I think I'm going to go back to MC-18.

Perhaps JRiver should accept that they may be wrong.  Kudos to 6233638 for trying to keep it professional.