INTERACT FORUM
More => Old Versions => JRiver Media Center 19 for Mac => Topic started by: jomal on April 04, 2014, 02:44:46 pm
-
Hi.
I'm evaluating a copy of JRiver 19.0.122 in my MacBook Pro / OS X Mavericks and everything seems good but the "play files from memory instead of disk" (PFFM) option. Whenever it's enabled and the music file comes from a LAN NAS (100Mbps ethernet) the music hangs during playback for up to 10s and then it's resumed. However the problem appears again in the next file playback. The problem seems to be more effective when playing HD files (>24b/48K).
The attached files show my configuration as saved by MC 19 (PDF file) and three other logs reporting the playback of 16b/44.1K FLAC files. The first one reports the playback with the PFFM option disabled, where everything goes flawless, and then two other logs with PFFM option enabled. In the second try the music time counter stops at 38s and resumes after 5s with no music stopping. However in the third try with another music, the counter stops at 39s and the music stops hereafter, resuming after about 10s.
Thanks for your help!
-
You would lose nothing by turning off the play from memory option.
-
You're probably right JimH, unless by the possibility to check it up by myself. ;) I see no reason for the program to hang on and then hang out.
-
The point of memory playback is to satisfy those who feel there is an audio benefit when the system is under minimal usage.
It is going to take approximately 10 seconds to transfer a 100Mb FLAC file over your 100Mbit/s network.
In order to avoid intra-track gaps, MC has to start copying before the track has completed... thereby defeating the very purpose of memory playback (which is to minimize system usage).
So what should MC do - buffer at the end of each track until the entire track is received? Or pull the next track while the current track is playing (thereby defeating the point of memory playback).
So in your usage scenario, its best to disable memory playback and let MC and the OS' network stack do what they do best.
-
You would lose nothing by turning off the play from memory option.
What a solution!! If it doesn't matter, and you don't want to support it, then why even pay the lip service and put it in the program?
I have it enabled on my Mac version and it plays gaplessly and without drops over WAN at home and over WAN/LAN when traveling.
-Patrick
-
Time to read:
http://yabb.jriver.com/interact/index.php?topic=81982.0 (http://yabb.jriver.com/interact/index.php?topic=81982.0)
-
Time to read:
http://yabb.jriver.com/interact/index.php?topic=81982.0 (http://yabb.jriver.com/interact/index.php?topic=81982.0)
Pertinent info from above:
"Technical Considerations
With a modern computer, playback of a standard CD-quality file will have the fully decoded file in memory in around one second.
Memory playback will use up to 1GB of memory for cache (capped at 80% of available system memory to avoid swap usage).
In some cases, the work of decoding and caching a file quickly as a track starts could lead to other problems. For example, when playing over Wi-Fi some machines exhibit high resource usage when reading a file quickly. This resource usage as a track starts could lead to audio playback glitches.
Some files like DSD played as PCM have very large decoded data so that they might require more memory to cache than (most) any system has. In these cases, the program will cache 1GB, play it mostly out, then cache another 1GB, etc.
With memory playback enabled, the player will no longer report a real-time bitrate (ie. 872 kbps) during playback. This is because asking the decoder its current bitrate is not possible when the decoder has finished with the current track completely in the first couple seconds of playback."
-
see below..... ;)
-
No network stack is 100% efficient.
"100Mb FLAC file over your 100Mbit/s network."
Should read "100MB file over your 100Mb
If on standard 1MB (bytes) contains 8Mb (bits), then you would have 12.5 bytes per second, or 8 seconds. Not to split hairs.... just clarifying the nomenclature.
But aren't we getting about 1000Mb/sec with Cat5 and ~300 with Wireless N?
-p
There are enough inaccuracies here that you'll want to clean it up if you're going to split hairs. :-)