Jump to content
IGNORED

JRiver tips and techniques: user experiences repository


ted_b

Recommended Posts

Are you checking this on Windows or MAC ? What tool ? If it is another core/thread that is 100% loaded then it is ok. From a sound quality point of view the writing thread should respond to IO from the device right away, way within the max limits allowed. May be that 1/10 CPU is not good enough that way.

At work, depending on the query/processing (IO vs CPU) we use compressed or uncompressed data.

Windows, via Process Explorer.

 

I get smoother SACD playback by limiting JRiver to 1 CPU core instead of letting it use all four now.

This interferes with other tasks like audio analysis, conversions, and video playback though.

 

In v18 this was not necessary at all. Using the v18 method of memory playback (storing the track in memory instead of decompressing it into memory) and extending that by caching multiple tracks instead of only the currently playing track would be a much better use of memory than the current method.

Link to comment
Has anyone found a way to no longer get the pop up message in Jriver when Jremote tries to get access, and to automatically allow?

 

It states:

 

Do you want the application "Media Center 20.app" to accept incoming network connections?

 

This happens with Firewall on or off, and even with JRMC added to the list to allow incoming connections in the Firewall setup.

 

Thanks!

 

Sorry, I forgot to mention that this is on a Mac version of Jriver MC.

Link to comment
Hi Paul,

 

It is intriguing how little they believe hardware makes a difference, but I was glad to see this function included. When memory playback is selected in JRMC, do you know how much it loads: album, song, # of songs?

 

In Amarra there is an option to choose, but I could not find it in JRMC.

 

Cheers

 

A bit more experimentation, and I found a possible solution. Just in case someone else has run into this. I had the Firewall on and had selected JRMC as an application that was allowed to accept all incoming connections. However, every time Jremote tries to connect, a pop-up message asks for confirmation. When you are running any optimization scripts like the CAD ones, this pop-up does not show and Jremote is blocked.

 

Solution - Disable firewall

 

Note - Just toggling the firewall settings will not help unless you do a reboot.

Link to comment
Windows, via Process Explorer.

 

I get smoother SACD playback by limiting JRiver to 1 CPU core instead of letting it use all four now.

This interferes with other tasks like audio analysis, conversions, and video playback though.

 

In v18 this was not necessary at all. Using the v18 method of memory playback (storing the track in memory instead of decompressing it into memory) and extending that by caching multiple tracks instead of only the currently playing track would be a much better use of memory than the current method.

 

I will try tonight on my windows PC. BTW, how did you make it run on single core ?

I also feel making JRiver, which apparently is multi-threaded, run on single core will surely cause hiccups.

Link to comment
I will try tonight on my windows PC. BTW, how did you make it run on single core ?
Setting the processor affinity will let you do this.

 

I also feel making JRiver, which apparently is multi-threaded, run on single core will surely cause hiccups.
It may depend on your CPU speed. It's certainly smoother on my system, and means it no longer interrupts other processes.

I have to say that I was wrong though, after revisiting this. v20 with memory playback disabled is no worse than v18.

 

It's only when Memory Playback is enabled and has access to all CPU cores that it uses enough CPU to interfere with other processes on the system.

I also don't see the benefit to memory playback in its current state, when it has to continually refill the buffer during playback like this.

It should cache the file, instead of filling up a 1GB buffer every few minutes.

 

The CPU usage scale is fixed, the others seem to be dynamic and I couldn't see an option to assign a scale.

I/O peaked around 650KB/sec for all but the 4-core graph, where it was over 4MB/s.

JRiver 18.png

JRiver 20.png

Memory Playback (4 cores).png

Memory Playback (1 core).png

Link to comment

Of course I would return to this and find that I forgot to attach the most important graph - v18's memory playback of the same tracks.

 

Big spike of I/O (113MB/s peak) for a brief moment at the start of playback, and then nothing at all. Not even 650KB/s, 0KB/s.

Much lower CPU usage during playback - no different from having the option disabled.

Much lower memory usage, enough spare to cache several tracks ahead.

v18 Memory Playback.png

Link to comment
  • 2 weeks later...

One more CRUCIAL thing to know is make sure that you go into Tools->Options-> DSP Settings and uncheck every box, especially the top one, if you want bit perfect playback.

 

Otherwise you might have thought you were listening to 24/192 but it was transcoded down.

 

Cheers

Link to comment
One more CRUCIAL thing to know is make sure that you go into Tools->Options-> DSP Settings and uncheck every box, especially the top one, if you want bit perfect playback.

 

Otherwise you might have thought you were listening to 24/192 but it was transcoded down.

 

Cheers

If you are talking about DSP Studio and Output Format I am not certain that is necessarily correct. For instance my selections for Input 44.1 and 48 are Output 88.2 and 96 but for Input 88.2, 96, 176.4, 192 my Ouput is No Change. Are you saying even with No Change selected and Output Format checked they are not bit perfect?

"A mind is like a parachute. It doesn't work if it is not open."
Frank Zappa
Link to comment
@Skeptic - looks like you want people/JRiver to accept your design idea of keeping data compressed in memory. As somebody who has programmed with uncompressed/compressed data on disk/memory my take is - the performance benefits can only conclusively be told with a benchmark. In the case of audio, this memory playback itself, is a very, "esoteric" feature. It may or may not have effects on sound quality. DSD/High-Res is used mainly by audiophiles and not mainstream customers. I am pretty sure JRiver will handle well without memory playback. If you have memory playback turned on you are an audiophile and now we are in a different discussion. I am with Paul on this. It is highly likely with the current CPU powers, a single thread de-compressing and playing back the data may lose the 'supposed' advantages of memory playback.

 

Well said.

Jim Hillegass / JRiver Media Center / jriver.com

Link to comment
Well said.
Well said? I have provided data to back up my post.

Everything else seems to be conjecture, and things suddenly went quiet on the subject once that data was posted.

 

Memory Playback in v18 is better in every way except for SACD ISO playback which is a case of "one step forward, two steps back".

 

+ Now stores tracks in memory (previously, tracks from ISOs were not stored in memory at all)

− Uses the new memory playback system

   − Wastes memory, and is only able to fit partial tracks in RAM now

   − No longer eliminates I/O during playback

   − Uses too much CPU, interrupting other processes on the system, or its own playback

Link to comment

Skeptic, your position on memory playback is well understood.

 

JRiver disagrees. We think it's a big win having the decoded data in memory. This makes FLAC, APE, WAV, etc. playback identical after a split second. It's a big win, from our perspective.

 

We'll agree to disagree.

Matt Ashland, JRiver

Link to comment
Skeptic, your position on memory playback is well understood.

JRiver disagrees. We think it's a big win having the decoded data in memory. This makes FLAC, APE, WAV, etc. playback identical after a split second. It's a big win, from our perspective.

We'll agree to disagree.

After a split second... several times during the playback of a single track... with a significant CPU impact.

 

Rather than storing the entire track in memory and eliminating I/O as every other Memory Playback implementation in every other player does.

Link to comment
Well said? I have provided data to back up my post.

Everything else seems to be conjecture, and things suddenly went quiet on the subject once that data was posted.

 

Memory Playback in v18 is better in every way except for SACD ISO playback which is a case of "one step forward, two steps back".

 

+ Now stores tracks in memory (previously, tracks from ISOs were not stored in memory at all)

− Uses the new memory playback system

   − Wastes memory, and is only able to fit partial tracks in RAM now

   − No longer eliminates I/O during playback

   − Uses too much CPU, interrupting other processes on the system, or its own playback

 

Not exactly, more like everyone just got tired of arguing with you I think. Note again, you can have exactly what you want by turning off memory play - the OS will cache the uncompressed/unprocessed data in memory, giving you a slight bump at the start of a series of contiguous tracks, and little or no disk access while playing. This produces a different processing signature that you seem to prefer.

 

The end result is what sounds better for you. I can't hear any difference in playback on a Mac Mini with 4gb or a Mac Pro 6 core with 64GB of memory, using JRMC. Except the Pro makes a little bit more noise, and I cannot afford to dedicate it as a music server.

 

-Paul

Anyone who considers protocol unimportant has never dealt with a cat DAC.

Robert A. Heinlein

Link to comment
Note again, you can have exactly what you want by turning off memory play - the OS will cache the uncompressed/unprocessed data in memory, giving you a slight bump at the start of a series of contiguous tracks, and little or no disk access while playing. This produces a different processing signature that you seem to prefer.
It is not about a "processing signature", it's about sensible resource usage.

And the OS does not cache the tracks in memory as you seem to assume - that's why the feature exists.

 

I just did a quick test, and in v18 I can play 18 channels of DSD at once (6 channel tracks to three locations) the memory usage peaked at about 600MB, and CPU usage was below 60% on average.

Other than the very start of each track, there was no disk access at all.

 

In v20 with Memory Playback enabled, trying to play a 6 channel DFF track in a single location results in CPU usage above 90%, disk access during playback, and memory usage over 1GB. The buffer is constantly emptied and refilled as a result of that.

When I tried playing to two locations (12 channels) it worked to begin with, but playback stuttered and eventually one of the zones just stopped playing anything.

 

 

So in v18 I can be playing to three different rooms at once and still be using the computer for other tasks at the same time.

 

In v20 I can't do anything else on the PC if Memory Playback is enabled, even if it's just playing to a single location.

And if the option is disabled, it's prone to interruption if another program is accessing the disk/network at the same time.

 

Things are definitely fine the way they are.

Link to comment
It is not about a "processing signature", it's about sensible resource usage.

And the OS does not cache the tracks in memory as you seem to assume - that's why the feature exists.

 

Nooo- the feature exists because Audiophiles asked for it and many think it sounds better.

 

All popular OS's cache disk access in memory, including Windows. Certainly MacOS, Linux, or any Unix derived OS will do that very very well.

 

-Paul

 

 

I just did a quick test, and in v18 I can play 18 channels of DSD at once (6 channel tracks to three locations) the memory usage peaked at about 600MB, and CPU usage was below 60% on average.

Other than the very start of each track, there was no disk access at all.

 

In v20 with Memory Playback enabled, trying to play a 6 channel DFF track in a single location results in CPU usage above 90%, disk access during playback, and memory usage over 1GB. The buffer is constantly emptied and refilled as a result of that.

When I tried playing to two locations (12 channels) it worked to begin with, but playback stuttered and eventually one of the zones just stopped playing anything.

 

 

So in v18 I can be playing to three different rooms at once and still be using the computer for other tasks at the same time.

 

In v20 I can't do anything else on the PC if Memory Playback is enabled, even if it's just playing to a single location.

And if the option is disabled, it's prone to interruption if another program is accessing the disk/network at the same time.

 

Things are definitely fine the way they are.

Anyone who considers protocol unimportant has never dealt with a cat DAC.

Robert A. Heinlein

Link to comment
Nooo- the feature exists because Audiophiles asked for it and many think it sounds better.
It's supposed to use more memory to make playback far more difficult to interrupt.

That improves sound quality, since it prevents other processes on the computer interrupting playback.

 

All lossless/uncompressed formats sound the same, so Memory Playback will have no impact on audio quality.

 

And if you believe that the decompression is causing lossless/uncompressed formats to sound different, the new Memory Playback has spikes of almost 100% CPU usage and disk/network access during playback, while the old Memory Playback was <25% CPU and had no disk/network access.

 

All popular OS's cache disk access in memory, including Windows. Certainly MacOS, Linux, or any Unix derived OS will do that very very well.
Not in the way that you're thinking. This is easy to test:

Play a track located on a portable drive.

Force eject the drive and remove it from the system.

 

v18 with memory playback enabled: plays track to completion (about 5 minutes)

v20 with memory playback enabled: plays track for approximately 60 seconds and then stops

 

Without memory playback, both v18 and v20 stop playback almost immediately, as expected. The OS does not cache the track in memory as you are suggesting.

 

Now instead of the removal of a portable drive, imagine that it is:

A disk which is busy due to another process running on the system (e.g. automated backup)

A slow network connection

A NAS which has gone to sleep and takes longer than the ~20s to wake up that JRiver allows for

A WiFi connection which has dropped, or a notebook changing access points

Any other number of things which could result in slow disk/network access.

 

With v18 memory usage is low enough that you could cache more than one track and store at least 15 minutes of 6ch DSD using the same memory as v20 uses for about 60 seconds.

 

 

I'm sure that your response will be well that doesn't affect me, or to say that anyone using JRiver for playback should invest in faster disks/networking hardware and build a dedicated PC for music playback, but that is absurd. It's a software issue, not a hardware one, and something which was in a far better state before the changes they made in v19.

Link to comment

I think you are missing Matt's point, JRMC is more than just a player for 6ch DSD. I'm not fond of the incorporation of videos and pictures but if that's what JRMC needs to do in order to "feed the business" then I'm all for it. I would rather them stay in business and mature the product than have it go stale due to stagnation.

 

I tried your test with a large single DSD 2ch track (sorry but I don't have any multichannel files). It was from Mahler and the file was 1.4GB. I watched my network activity as I started the track, I could see it load data, and then after about 10 seconds I disconnected my NAS from the network. JRMC played the entire track without a hickup - though Windows popped up a dialog box reminding me that the attached drive was no longer available.

 

Perhaps your problem only exists if; a) you have a VERY large file (like a 6ch DSD), and b) you have a moderate PC with a moderate amount of RAM. Now let's look at JRMC's total audience and see what percentage this restraint falls into - probably a pretty small number.

 

I guess what I've learned from this is that if I want to go down the multichannel DSD path then I should have a pretty beafy PC, possibly 32GB of RAM, or maybe even 64GB.

Analog: Koetsu Rosewood > VPI Aries 3 w/SDS > EAR 834P > EAR 834L: Audiodesk cleaner

Digital Fun: DAS > CAPS v3 w/LPS (JRMC) SOtM USB > Lynx Hilo > EAR 834L

Digital Serious: DAS > CAPS v3 w/LPS (HQPlayer) Ethernet > SMS-100 NAA > Lampi DSD L4 G5 > EAR 834L

Digital Disc: Oppo BDP 95 > EAR 834L

Output: EAR 834L > Xilica XP4080 DSP > Odessey Stratos Mono Extreme > Legacy Aeris

Phones: EAR 834L > Little Dot Mk ii > Senheiser HD 800

Link to comment
I think you are missing Matt's point, JRMC is more than just a player for 6ch DSD. I'm not fond of the incorporation of videos and pictures but if that's what JRMC needs to do in order to "feed the business" then I'm all for it. I would rather them stay in business and mature the product than have it go stale due to stagnation.
How does increasing the system requirements for an existing feature and reducing performance help things?

 

I tried your test with a large single DSD 2ch track (sorry but I don't have any multichannel files). It was from Mahler and the file was 1.4GB. I watched my network activity as I started the track, I could see it load data, and then after about 10 seconds I disconnected my NAS from the network. JRMC played the entire track without a hickup - though Windows popped up a dialog box reminding me that the attached drive was no longer available.
If it managed to play without a network connection, they must be creating a copy of the track on a local drive and playing it from there instead.

At 1.4GB that track is too large for even v18 to completely cache it in memory, since it's limited to 1GB for some reason.

 

The track I used for the test above was only 219MB in size, which is why it completely fits into memory in v18, yet the buffer has to be refilled several times during playback in v20 - each being a potential failure point due to slow/unavailable disk access, or CPU usage from other processes.

 

It's very difficult to get playback to fail in v18. I can consistently have playback fail in v20 due to other processes running on the PC (including JRiver's own audio analysis) and JRiver itself interferes with the operation of other programs running at the same time when the memory playback feature is enabled.

 

Even if it were a 64-bit application and had access to as much RAM as it wanted - taking up several gigs for a single track (which is, again, totally absurd) that would make the CPU usage worse than it currently is now since it would be decompressing the whole track at once rather than only 60-second chunks. So rather than bursts of 10-15 seconds with nearly 100% CPU activity, it could be several minutes with nearly 100% activity as the track is decompressed. So even if this change was supposed to have been rolled into a 64-bit version of the application which was then put on hold, it still needlessly hurts performance.

 

 

And if it's playing your 1.4GB track from a local drive rather than your network, there is the other potential issue where the NAS is now idle long enough to sleep, and JRiver only allows for about 20 seconds for it to wake up & transfer the next track if you want gapless playback.

It's a similar problem if the NAS is active, but currently in use by another user and the connection is too slow.

 

Using the older method of memory playback generally leaves enough memory free that you could cache multiple tracks in advance to prevent that from ever being an issue. It's extremely rare to have tracks larger than about 500MB in size in my experience, unless you are converting DFF to DSF and removing the DST compression.

 

 

But rather than just post examples, the real-world impact is that I've not been able to use memory playback since this change was made, and playback without it is prone to interruption. For a placebo.

 

Perhaps your problem only exists if; a) you have a VERY large file (like a 6ch DSD), and b) you have a moderate PC with a moderate amount of RAM.
JRMark of about 5000 and 8GB RAM. Since the program is 32-bit, it could not use more than 4GB anyway.

Not that it does, the memory playback cache is limited to 1GB.

 

The issue is not the PC's speed, or how much memory it has, but how that power and memory is utilized - which is why v18 can handle 18 channels of DSD on my system while v20 struggles with 6.

Link to comment
It's supposed to use more memory to make playback far more difficult to interrupt.

That improves sound quality, since it prevents other processes on the computer interrupting playback. [/Quote]

 

I see that is what you think it does.

 

All lossless/uncompressed formats sound the same, so Memory Playback will have no impact on audio quality.[/Quote]

An unfounded and unsupported theory. There is plenty of evidence that different lossless and uncompressed formats can sound different. The explanations as to why that is possible range from common sense to utterly ridiculous, but just the same...

 

And if you believe that the decompression is causing lossless/uncompressed formats to sound different, the new Memory Playback has spikes of almost 100% CPU usage and disk/network access during playback, while the old Memory Playback was <25% CPU and had no disk/network access.

 

Not in the way that you're thinking. This is easy to test:

Play a track located on a portable drive.

Force eject the drive and remove it from the system.

 

Actually, yes, it works exactly the way I said. Testing here uncovered exactly the predicted behavior. As expected the track played through to completion and errored the next time it tried to access the disk. I say as expected, because that is totally out of J. River's provenance, unless they memory map files. And, I am only playing stereo tracks.

 

 

I'm sure that your response will be well that doesn't affect me, or to say that anyone using JRiver for playback should invest in faster disks/networking hardware and build a dedicated PC for music playback, but that is absurd. It's a software issue, not a hardware one, and something which was in a far better state before the changes they made in v19.

 

Not exactly, but expecting audiophile performance and consistency from a non-dedicated music server machine *is* absurd. You cannot have your cake and eat it too, at least not unless you are willing to compromise somewhere or another.

 

You can take a Mac Mini for $599 and have a dynamic and very good sounding little music server for no additional cost IRT the computer. You can spend incremental amounts and improve the sound time and time again. This is not speculation, not only myself, but countless other people do the exact same thing.

 

Whatever has managed to get your goat about JRMC is, I think, driving your opinion far more than fact.

 

-Paul

Anyone who considers protocol unimportant has never dealt with a cat DAC.

Robert A. Heinlein

Link to comment
Actually, yes, it works exactly the way I said. Testing here uncovered exactly the predicted behavior. As expected the track played through to completion and errored the next time it tried to access the disk. I say as expected, because that is totally out of J. River's provenance, unless they memory map files. And, I am only playing stereo tracks.
You must be playing files which are small enough to fit inside the 1GB buffer even when decompressed then, since anything which does not has to access the disk several times during the track.

The issue is that you previously needed extremely long tracks to exceed the 1GB buffer, but with multichannel DSD it can now only store about 60 seconds of music until it has to access the disk again.

 

Not exactly, but expecting audiophile performance and consistency from a non-dedicated music server machine *is* absurd. You cannot have your cake and eat it too, at least not unless you are willing to compromise somewhere or another.
Memory Playback in v18 makes playback 100% consistent and extremely difficult to interrupt in the middle of a track. (easy to interrupt gapless playback though)

 

v20 is very easy to interrupt during playback, and v20 itself interrupts other programs when memory playback is enabled since it has to frantically try and decompress the track as quickly as possible every 60 seconds to refill that buffer.

 

The idea that you should need a dedicated PC for this task is ridiculous. Especially when v18 managed it just fine.

JRiver does so many things well. It's disappointing to see such a step backwards in performance and memory usage, and I'm surprised that anyone here would prefer a playback method which creates more CPU and disk activity during playback than before.

 

The only thing which needed to change was the way that gapless playback was handled and it would have been perfect.

Link to comment

Re-running the test right now in real time (Mahler No. 6, last track, 1.2GB, 29 minutes). I am monitoring the Ethernet port (which I have now disconnected after 30 seconds into the track, it pretty much went dead right after the initial load when the track started) and Disk 0 (my internal SSD).

 

I do see a little bit of disk activity but it's actually writing more than it is reading, I suspect that Windows is doing some house cleaning. Note, I am NOT running any Windows optimizers, this is raw 8.1 with 16GB of RAM. This is pretty cool because I am managing JRMC through JRemote on an iPad mini, typing this on an iPad 2, while the 60" display is covered with different system monitors from Task Manager.

 

When the track first starts I get a burst of network activity, some disk activity (though most of it is read), and my CPU usage goes up from 12% to about 21%. A lot of teeny tiny disk hits (24KB/s for 1ms, a big hit is 53KB/s for 2.1ms), and most of the activity is write. Just got a pretty big read at the 4 minute mark (maybe a MB of traffic). 8 minutes into it, the SSD is pretty much flat, mostly 0% with an occasional small hump to 5%. For clarity, I am assuming Write is writing to the disk (since I am monitoring the disk) and read is reading from the disk. The Disk Transfer Rate scale is at 100 KB/s and the little pops I see are at the 20-ish % Mark, the Active Time scale (measured in percent) is basically flat at 0% with occasional ripples that might get up to 5%. 11 minutes in and I got another ~1MB pop (read). 18 minutes and no real disk activity, metrics read; CPU 2%, Memory 20%, Disk 0%. Got another ~1MB pop at 19 minutes (read). And that's all she wrote.

 

For kicks I selected the first track to play next. Interesting, I saw the expected Ethernet activity as it pulled the file off the NAS, but I saw no difference in the SSD's activity. Memory stayed at 20%, pressed Stop and memory dropped to 14%.

 

Overall I would say that JRMC did NOT have this 1.2GB cached to disk, nor any reasonable portion of the file. I am running JRMC in Memory Mode and I have way more memory than 1.2GB. It seems to me, on my setup, that JRMC is faithfully running Memory Mode as advertised.

 

Edit: I actually ran this 1 1/2 time -yawn. The first time at about the half way mark I accidentally hit the play button in JRemote and everything froze because the NAS was unplugged. I plugged it back, and had to reboot it, and left it in for the rerun of the test. So the NAS was plugged in with verified no activity.

Analog: Koetsu Rosewood > VPI Aries 3 w/SDS > EAR 834P > EAR 834L: Audiodesk cleaner

Digital Fun: DAS > CAPS v3 w/LPS (JRMC) SOtM USB > Lynx Hilo > EAR 834L

Digital Serious: DAS > CAPS v3 w/LPS (HQPlayer) Ethernet > SMS-100 NAA > Lampi DSD L4 G5 > EAR 834L

Digital Disc: Oppo BDP 95 > EAR 834L

Output: EAR 834L > Xilica XP4080 DSP > Odessey Stratos Mono Extreme > Legacy Aeris

Phones: EAR 834L > Little Dot Mk ii > Senheiser HD 800

Link to comment
Overall I would say that JRMC did NOT have this 1.2GB cached to disk, nor any reasonable portion of the file. I am running JRMC in Memory Mode and I have way more memory than 1.2GB. It seems to me, on my setup, that JRMC is faithfully running Memory Mode as advertised.
Is this an uncompressed WAV/AIFF track? The maximum size is supposed to be 1GB but perhaps there is a 20% allowance for particularly big tracks.

If it's not an uncompressed track, then it cannot fit inside the memory buffer and has to be be loading in from somewhere.

 

Process Explorer will let you monitor the JRiver process specifically, rather than looking at generalized process usage in Task Manager.

Link to comment
You must be playing files which are small enough to fit inside the 1GB buffer even when decompressed then, since anything which does not has to access the disk several times during the track.

The issue is that you previously needed extremely long tracks to exceed the 1GB buffer, but with multichannel DSD it can now only store about 60 seconds of music until it has to access the disk again.

[/Quote]

 

There is no 1GB buffer limitation with the OS buffering, it will use all the memory available in a 64bit OS (save for the restrictions off consumer grade CPUs.) You can try running on MacOS or Linux to see this clearer, but Windows does buffer things up, which is why I suggested that even a 32bit application benefits from being ran on a 64bit or better OS.

 

Memory Playback in v18 makes playback 100% consistent and extremely difficult to interrupt in the middle of a track. (easy to interrupt gapless playback though)

 

v20 is very easy to interrupt during playback, and v20 itself interrupts other programs when memory playback is enabled since it has to frantically try and decompress the track as quickly as possible every 60 seconds to refill that buffer.

 

This is some artifact of your system, not a general thing that affects everyone.

 

The idea that you should need a dedicated PC for this task is ridiculous. Especially when v18 managed it just fine.

JRiver does so many things well. It's disappointing to see such a step backwards in performance and memory usage, and I'm surprised that anyone here would prefer a playback method which creates more CPU and disk activity during playback than before.

 

The only thing which needed to change was the way that gapless playback was handled and it would have been perfect.

 

Well, you state that like a fact, and it is anything but. Do you use your refrigerator to cool your home? How about using a lamp to heat a room?

 

What in the world makes you think a single computer should be the jack of all trades?

 

It can do so of course, but then, it will be the master of none, certainly not audio playback. With any OS or player software.

 

-Paul

Anyone who considers protocol unimportant has never dealt with a cat DAC.

Robert A. Heinlein

Link to comment

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 account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...