BobAudio Posted August 20, 2014 Share Posted August 20, 2014 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. Link to comment
maurodelfino Posted August 20, 2014 Share Posted August 20, 2014 Dear Bob, I've never used JRiver, but as a developer, allow me consider two things: - JRiver, as any Java application, runs on top of a Virtual Machine (JVM). Try to allocate more memory to this VM. I don't think there's any (well done) audio application that needs more than 512MB to run (very) well. How to do this: Look for -Xms and -Xmx parameters in the startup of JRiver (or the JVM) and set xms to 512MB (start) and xmx to 1024GB (max). - Network trafic often is specified in Mbps (Mega bits per second, with lower cap 'b'). MBps (Mega bytes per second, with upper cap 'B') is a set of 8 bits and is often used to display the file copy speed, for example. So, Byte = bit*8 So, 12 MBps is approxymately the same as 100 Mbps, which maybe the top velocity of your network (interface, router or NAS). Hope this helps. Sincerely, Mauro Delfino 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. Link to comment
jriver Posted August 21, 2014 Share Posted August 21, 2014 JRiver isn't a Java app. Playback problems could be related to bandwidth available, CPU power, or antivirus. An Atom based machine doesn't have a lot of computing power. Jim Hillegass / JRiver Media Center / jriver.com Link to comment
ted_b Posted August 21, 2014 Share Posted August 21, 2014 Bob, As Jim (jriver) says, DSF playback could be hindered by a few things. Just as a persepctive though, I have played plenty of DSF files (even DSD128 or multichannel 5.1 DSD) on an Atom-based CAPS JRiver19 (yes, my i5 or i7 playback is better) and experienced no stuttering once everything was set up. I don't do memory playback, but I do have wired ethernet connections. Moreover, it could be a DAC driver thing. What is your DAC, and what kind of driver are you using? Is your DoP set correctly (later versions of JRMC19 auto correct it anyway)? And where does Windows Media Server come in here? "We're all bozos on this bus"....F.T. My JRIver tutorial videos Actual JRIver tutorial MP4 video links My eleven yr old SACD Ripping Guide for PS3 (needs updating but still works) US Technical Advisor, NativeDSD.com Link to comment
BobAudio Posted August 22, 2014 Author Share Posted August 22, 2014 1) Thanks for the response. 2) I have a Weiss DAC202 and am using the Weiss driver. 3) I do not know anything about the proper DoP settings. Teb_b can you fill me in. 4) I'm simply connecting my JRiver dedicated PC to my HP Windows Media server (where my audio files are stored) via a mounted drive \ folder share. 5) I stopped using "playback from memory" setting as of last night since it hasn't really worked properly since JRiver V18 I'm told ( Playback stuttering even with "Play files from memory instead of disk" options s ) 6) I am trying to see if a hard wired connections improves things. I'll keep you posed. Again, thanks for the input. Link to comment
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now