JRiver tips and techniques: user experiences repository

[SamTheSham968]

Matt,

 

Thanks, will post at JRiver as well. Just for readers of this thread: I set the device settings software buffering to the maximum (500 ms), as recommended by iFi. I also tried maximum hardware buffering (as well as maximum power of two). This seems to have improved, maybe eliminated, the "pop" on startup from a stopped MC player. But the pop remains, loud and annoying, whenever a track is stopped (not paused), and whenever a track ends on segue to the next track, if and only if the next track is a change in file type (from DSD to PCM or vice versa).

[tranz]

It sometimes does take some encouragement to get them to believe that doing something is worthwhile (Mac version, memory play done correctly, etc.) but they always come through and do a great job. Even if they don't always believe that what they are being asked for will make a great deal of difference. (grin).....

 

-Paul

 

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

[tranz]

Thanks Ted for starting this thread and making those videos! Not sure why JRiver does not have at least a Getting Started PDF guide with screenshots and a few step-by-step instructions. The Wiki is not exactly user friendly for someone who just installed it.

 

Cheers

[Paul R]

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

 

I think I knew at one time, but I have definitely slept since then, and that knowledge has long since slipped out of my memory. I *think* it preloads a certain number of tracks, but I am not sure. I know it does gapless playback without any issue. I think I remember from testing that it sure sounded a lot better to me.

 

Remember, a large percentage of their customers are not audiophiles, so the things that we hear and are important to us are of far less concern to a lot of their customers. What is really the mark of a good company is that they listen to we audiophiles and do try to address the issues that re important to us.

 

Of course, they hem and haw a bit, declaring that such and such could not possibly make a difference. But they do it anyway, and usually get it right on the first or second try.

 

Implementing memory play is a good example of that. Their first attempt was not very good, and I think they were more than a little surprised that Audiophiles could tell it wasn't up to snuff and complained about it. Their second attempt at memory play worked much better and garnered a lot of praise for the audiophile community. I think that surprised them almost as much, since they honestly did not believe it would make any audible difference. Now it works flawlessly, so far as I can tell.

 

Anyway, I expect that Matt or Jim will answer this for you in a day or two, as soon as they see the posting. You could ask on their Interact forum, but honestly, for Audiophile answers, I believe this is a better forum.

 

 

-Paul

[tranz]

Thanks Paul. Once I have it configured properly I want to do a taste test with Amarra, but from a user functionality perspective it is in a separate league.

[firedog]

I have the pop when switching between tracks that are in different sample rates - but only over USB, not FW. So it apparently is either a driver or DAC issue, and not the software.

 

Matt,

 

Thanks, will post at JRiver as well. Just for readers of this thread: I set the device settings software buffering to the maximum (500 ms), as recommended by iFi. I also tried maximum hardware buffering (as well as maximum power of two). This seems to have improved, maybe eliminated, the "pop" on startup from a stopped MC player. But the pop remains, loud and annoying, whenever a track is stopped (not paused), and whenever a track ends on segue to the next track, if and only if the next track is a change in file type (from DSD to PCM or vice versa).

[Paul R]

I have the pop when switching between tracks that are in different sample rates - but only over USB, not FW. So it apparently is either a driver or DAC issue, and not the software.

 

I think you can set it to play a bit of silence between tracks with different sample rates, which takes care of any DAC problems with pops and clicks and so forth. It doesn't hurt at all when you are playing albums, because the vast majority of the time, all the album tracks are at the same sample rate and bit depth.

 

-Paul

[Skeptic]

Implementing memory play is a good example of that. Their first attempt was not very good, and I think they were more than a little surprised that Audiophiles could tell it wasn't up to snuff and complained about it. Their second attempt at memory play worked much better and garnered a lot of praise for the audiophile community. I think that surprised them almost as much, since they honestly did not believe it would make any audible difference. Now it works flawlessly, so far as I can tell.

You have that backwards. Their first implementation was very good. It used only as much memory as necessary, and was totally immune to slow disk/network access during playback.

 

Now it's a CPU and memory hog that is susceptible to interruption during playback, especially with SACD.

I can't use it at all on my system unless JRiver is the only application running.

 

It's still far from perfect, and is in a worse state than it used to be before the "audiophile" changes were made. But JRiver don't seem to care about performance issues now, only adding new features.

 

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.

It tries to decompress the current song into memory in as quick a time as possible, up to 1GB.

If the uncompressed audio is larger than 1GB (DSD/SACD) it will buffer several times during playback.

Each time it buffers is a chance for interruption since it's accessing the disk/network again, and CPU usage jumps to 100%.

The next track begins to buffer in the last 20 seconds of the current track - which is why playback stutters at the end of a track on slower systems now.

[hifitubes]

FWIW, Matt has stated explicitly on Interact to disable memory playback when using NAS.

 

 

Sent from my iPhone using Tapatalk

[Skeptic]

FWIW, Matt has stated explicitly on Interact to disable memory playback when using NAS.

It's a fixable problem. Just one they don't want to address.

[Jabs1542]

Maybe there is a hardware element to this. My CAPS is a Micro Zuma with an I7 and 16GB of RAM. I can monitor my Ethernet connection and watch a burst of network traffic at the beginning of each song, otherwise the network is dead (using a NAS). The playback is very good and the CPU usage is rarely above 1%. Memory playback seems to work well for me.

[Skeptic]

Maybe there is a hardware element to this. My CAPS is a Micro Zuma with an I7 and 16GB of RAM. I can monitor my Ethernet connection and watch a burst of network traffic at the beginning of each song, otherwise the network is dead (using a NAS). The playback is very good and the CPU usage is rarely above 1%. Memory playback seems to work well for me.

That's exactly why it is not recommended, as it only leaves 20 seconds at the end of each track to load the next one into memory or else playback may be interrupted.

They could be a lot smarter about it, like always caching the next two tracks in memory instead of only the currently playing one, and it would use less memory than the current playback system if they stored compressed audio instead of decompressing the file like they do now.

[jriver]

It's a fixable problem. Just one they don't want to address.

 

Problems reported by several users have a higher priority.

[tranz]

Thanks for the details Sceptic.

 

Amarra is limited to just under 3GB of cache load and you do hear the benefit of stopped traffic from the HD in Amarra. Have not listened closely to JRiver yet, but I assume the impact is similar. Too bad it will not work with a NAS.

 

Don't like the idea of having another process running to decompress files loaded in memory though.

[Paul R]

Thanks for the details Sceptic.

 

Amarra is limited to just under 3GB of cache load and you do hear the benefit of stopped traffic from the HD in Amarra. Have not listened closely to JRiver yet, but I assume the impact is similar. Too bad it will not work with a NAS.

 

Don't like the idea of having another process running to decompress files loaded in memory though.

 

Whoa there- many many people, including me use memory play with files on a NAS and JRMC. Skeptic is incorrectly presenting this as an absolute problem. I am not even sure Skeptic's description is even accurate.

 

JRMC gives problems when ran on a skimpy processor, like old single threaded Atoms. Almost sny modern machine does not see these problems. Inuse an i5 based mavhine and have zero troubles.

 

Also if you are using some low quality components on your network, you are going to have problems.

 

And if you believe those folks that will spend $5k on a DAC but balk at any computer that costs more than $300, or insist that sone no-name wireless router is as good as an Airport Extreme, then you will most likely have troubles.

 

And like I said, the folks at J. River are accomodating to audiophiles like us, even though they do not always believe the changes and features we ask for make a difference.

 

Lastly, this insistance some of you guys have on limiting processes and such is a big issue to swallow. Processes do not usually take up any CPU cycles unless they have some work to do. I would rather see concentration kn getting software to native 64 status, which woukd eliminate any memory constraints that may still exist in 32 bit software.

[Skeptic]

Whoa there- many many people, including me use memory play with files on a NAS and JRMC. Skeptic is incorrectly presenting this as an absolute problem. I am not even sure Skeptic's description is even accurate.

JRiver are the ones saying not to use it with a NAS, not me.

I explained the reason why they say this. It can work in some setups if your network connection is active and fast enough.

 

If you listen to a long track (say 20 minutes of classical music) and your network adapter (e.g. wireless card in a notebook) and NAS disks go to sleep, it might take longer than the 20 seconds or so JRiver give it to transfer and decode the next track. Depending on the hardware it might be significant and could even halt playback.

 

JRMC gives problems when ran on a skimpy processor, like old single threaded Atoms. Almost sny modern machine does not see these problems. Inuse an i5 based mavhine and have zero troubles.

Not true with SACD if you aren't bitstreaming. Try a multichannel SACD or DFF track. (not DSF)

 

And like I said, the folks at J. River are accomodating to audiophiles like us, even though they do not always believe the changes and features we ask for make a difference.

 

Lastly, this insistance some of you guys have on limiting processes and such is a big issue to swallow. Processes do not usually take up any CPU cycles unless they have some work to do. I would rather see concentration kn getting software to native 64 status, which woukd eliminate any memory constraints that may still exist in 32 bit software.

I'd rather see them use memory more efficiently so that would not be necessary. Store the track in RAM - or several - which is going to use less than a 1GB, instead of decoded audio which can be significantly larger.

 

A 580MB, 21 minute 6ch DFF becomes 7.4GB when you store it uncompressed.

This means the 1GB buffer has to be emptied and refilled eight times during playback, which requires significant CPU and disk/network access each time, instead of playing from a small buffer that results in a small but constant amount of CPU usage and no disk/network access.

Each time it does this, it interferes with anything else running on the computer, which did not happen before.

 

If you were to store the compressed tracks in memory, 1.6GB would store the entire album, resulting in zero disk/network access during playback. You would need 22GB with a 64-bit version of JRiver to store the album in memory uncompressed, and there would be 100% CPU usage and disk/network access for several minutes while it does this.

 

It's a stupid design to placate people who either think they can hear the difference when their CPU is busy/idle or believe that lossless/uncompressed tracks sound different.

And even if you do believe that is true, the current system results in higher CPU and disk/network access than before.

 

It's worse in every single way, no matter what you believe about things like CPU usage during playback.

[Paul R]

JRiver are the ones saying not to use it with a NAS, not me.

I explained the reason why they say this. It can work in some setups if your network connection is active and fast enough.

 

If you listen to a long track (say 20 minutes of classical music) and your network adapter (e.g. wireless card in a notebook) and NAS disks go to sleep, it might take longer than the 20 seconds or so JRiver give it to transfer and decode the next track. Depending on the hardware it might be significant and could even halt playback.

 

It is not hard to build home networks plenty fast enough to avoid this these days. This should not be an issue for anyone, and certainly not for anyone spending multi-thousands of dollars on audio equipment.

 

Not true with SACD if you aren't bitstreaming. Try a multichannel SACD or DFF track. (not DSF) [/Quote]

 

I only have a couple of DFFs, but they have no trouble at all streaming. No hiccups, stutters, or whatnot.

 

 

I'd rather see them use memory more efficiently so that would not be necessary. Store the track in RAM - or several - which is going to use less than a 1GB, instead of decoded audio which can be significantly larger.

 

A 580MB, 21 minute 6ch DFF becomes 7.4GB when you store it uncompressed.

This means the 1GB buffer has to be emptied and refilled eight times during playback, which requires significant CPU and disk/network access each time, instead of playing from a small buffer that results in a small but constant amount of CPU usage and no disk/network access.

Each time it does this, it interferes with anything else running on the computer, which did not happen before.

 

If you were to store the compressed tracks in memory, 1.6GB would store the entire album, resulting in zero disk/network access during playback. You would need 22GB with a 64-bit version of JRiver to store the album in memory uncompressed, and there would be 100% CPU usage and disk/network access for several minutes while it does this. [/Quote]

 

Well, believe it or not, we are saying something like the same thing here. You have to have a 64bit memory model to take advantage of more than about 3.6GB of RAM. With uncompressed audio files growing very large - well - one does need much more memory.

 

On the other hand, I am not convinced that totally decoding the file in a memory buffer is advisable.

 

It's a stupid design to placate people who either think they can hear the difference when their CPU is busy/idle or believe that lossless/uncompressed tracks sound different.

And even if you do believe that is true, the current system results in higher CPU and disk/network access than before.

 

It's worse in every single way, no matter what you believe about things like CPU usage during playback.[/QUote]

 

As I said, I think it is better than what they started with, and I believe I can hear a difference. That despite suspicions of exactly how they did it. (i.e. bumped up the buffer size, added a thread, etc. )

 

-Paul

[Skeptic]

It is not hard to build home networks plenty fast enough to avoid this these days. This should not be an issue for anyone, and certainly not for anyone spending multi-thousands of dollars on audio equipment.

It is not speed, but latency that is the issue. If JRiver cached the next couple of tracks instead of only allowing 20s to transfer and decode the next track, it would not be an issue on anyone's setup.

Even with a fast network, hard drives in a NAS can be slow to spin up.

 

I don't think it's fair to assume that everyone running JRiver is spending thousands and thousands of dollars on gear either.

 

I only have a couple of DFFs, but they have no trouble at all streaming. No hiccups, stutters, or whatnot.

If JRiver is the only thing using your computer, it's probably fine.

If other applications are running and accessing the same disk/network (e.g. copying files) and the current track requires more than 1GB RAM, playback can be interrupted in the current system, or it can pause for several minutes between tracks.

 

Well, believe it or not, we are saying something like the same thing here. You have to have a 64bit memory model to take advantage of more than about 3.6GB of RAM. With uncompressed audio files growing very large - well - one does need much more memory.

Do you really think it's smart moving to 64-bit so that caching a full album would require 22GB of RAM when 1.6GB will do the same job?

 

With the current 32-bit app and its 1GB buffer, you could already keep three full tracks in memory at once, or more depending on the format, instead of having to refill the buffer 8x during playback of a single track.

 

On the other hand, I am not convinced that totally decoding the file in a memory buffer is advisable.

It's not. Converting that same 580MB track to uncompressed WAV took two and a half minutes of 100% CPU usage on a fast quad-core i5, and required 3.9MB/s I/O.

 

If you believe that CPU usage and disk/network access affect playback quality, do you want the first two and a half minutes of a 21 minute track affected by this?

If you had a 64-bit version and decoded the full album into RAM, the entire first track would be played back with 100% CPU usage.

 

If it takes 150s of 100% CPU usage to decode the track as quickly as possible, that could be 21 minutes of 12% CPU usage instead, and only 0.46MB/s I/O.

With only 12% CPU usage, three of the CPU cores could sleep with only one being required for playback.

 

You also have to consider that many people use their computer for other tasks with music playing in the background, or want to play music to multiple rooms at once. If playing a single track eats up 100% of the CPU, there's nothing left for anything else.

 

That is why SACD tracks like this one which have to fill the buffer 8x over the course of 21 minutes is a serious problem, since it means that everything else on the PC is interrupted every few minutes, or other tasks on the PC can potentially interrupt playback in JRiver.

 

As I said, I think it is better than what they started with, and I believe I can hear a difference. That despite suspicions of exactly how they did it. (i.e. bumped up the buffer size, added a thread, etc. )

If you believe that you can hear a difference, do you hear an improvement?

Disk/network activity and CPU usage can be much higher during playback now.

 

With PCM formats this is a much smaller problem, since they are generally stereo, fit inside the 1GB buffer, and are a lot easier to decode compared to DST compression.

 

It would still be much more memory efficient to store compressed tracks rather than decompressing into memory, and this efficiency would allow you to store multiple tracks in advance, to greatly reduce disk/network access during playback, and the possibility of interruption.

[Paul R]

It is not speed, but latency that is the issue. If JRiver cached the next couple of tracks instead of only allowing 20s to transfer and decode the next track, it would not be an issue on anyone's setup.

Even with a fast network, hard drives in a NAS can be slow to spin up.

 

I don't think it's fair to assume that everyone running JRiver is spending thousands and thousands of dollars on gear either.

 

If they are worrying about the implementation of memory play, I suspect it is pretty safe to say they are an audiophile and have spent quite a chunk of change on their audio gear.

 

 

If JRiver is the only thing using your computer, it's probably fine.

If other applications are running and accessing the same disk/network (e.g. copying files) and the current track requires more than 1GB RAM, playback can be interrupted in the current system, or it can pause for several minutes between tracks.

 

If it is a music server, JRMC should well be about the only thing running on it. You can run other apps of course, but it is a compromise. The same is true of pretty much any other high end player as well, A+, HQPlayer, XXHigh End, etc.

 

Do you really think it's smart moving to 64-bit so that caching a full album would require 22GB of RAM when 1.6GB will do the same job?[/Quote]

 

If it did the same job, no. But it doesn't, and yes, it is smart to move up to 64bit processing now and be prepared to handle computers that routinely come with terabytes of memory. It isn't that far in the future.

 

 

With the current 32-bit app and its 1GB buffer, you could already keep three full tracks in memory at once, or more depending on the format, instead of having to refill the buffer 8x during playback of a single track.

 

It's not. Converting that same 580MB track to uncompressed WAV took two and a half minutes of 100% CPU usage on a fast quad-core i5, and required 3.9MB/s I/O.

 

If you believe that CPU usage and disk/network access affect playback quality, do you want the first two and a half minutes of a 21 minute track affected by this?

If you had a 64-bit version and decoded the full album into RAM, the entire first track would be played back with 100% CPU usage.[/Quote]

 

Only if you assume I am converting the album from DSD to PCM, which is something I just wouldn't do. I almost certainly would do the opposite though, and in fact, I do convert PCM to DSD for playback. If I really wanted to play it as PCM, I would convert it offline though.

 

I actually do rather agree with you though, both Windows and Unix based OS's already buffer all disk access into memory. That is very effective. To make the process more effective, you need to decode the data file into the format you are going to send to the DAC. There is little enough of that necessary with DSD, but a lot more of it necessary with PCM.

 

If it takes 150s of 100% CPU usage to decode the track as quickly as possible, that could be 21 minutes of 12% CPU usage instead, and only 0.46MB/s I/O.

With only 12% CPU usage, three of the CPU cores could sleep with only one being required for playback.[/Quote]

 

I honestly do not know where you are getting these numbers from- I can decode and re-encode a file much much faster than that, so I think your numbers are a bit off.

 

You also have to consider that many people use their computer for other tasks with music playing in the background, or want to play music to multiple rooms at once. If playing a single track eats up 100% of the CPU, there's nothing left for anything else.

 

That is why SACD tracks like this one which have to fill the buffer 8x over the course of 21 minutes is a serious problem, since it means that everything else on the PC is interrupted every few minutes, or other tasks on the PC can potentially interrupt playback in JRiver.

 

If you believe that you can hear a difference, do you hear an improvement?

Disk/network activity and CPU usage can be much higher during playback now.

 

With PCM formats this is a much smaller problem, since they are generally stereo, fit inside the 1GB buffer, and are a lot easier to decode compared to DST compression. [/Quote]

 

Well, yes and no. That PCM has to be decoded before it is buffered and sent to the DAC.

 

It would still be much more memory efficient to store compressed tracks rather than decompressing into memory, and this efficiency would allow you to store multiple tracks in advance, to greatly reduce disk/network access during playback, and the possibility of interruption.

 

If you mean send the compressed data over there network, I can see that. But it will still have to be decompressed and converted in memory anyway, I don't see a big deal about it. Even an 128kbs MP3 is actually decompressed into LPCM before being sent to the DAC. At least, in most cases.

 

The network queuing algorithm in JRMC is suboptimal, I will grant you that. It causes and is susceptible to packet queuing delays, which cause what you describe as latency. However, NAS that are not predictive and power down when they should not, networks too congested to reliably transfer traffic in a timely manner, and/or computers that are memory limited and depend upon weak processors are not something the J. River can be blamed for.

[Skeptic]

If they are worrying about the implementation of memory play, I suspect it is pretty safe to say they are an audiophile and have spent quite a chunk of change on their audio gear.

First and foremost, the feature should prevent interruptions during playback.

Whether or not it improves audio quality should be a secondary concern.

 

Since all lossless and uncompressed formats should sound the same, it should have no effect on quality.

 

If it is a music server, JRMC should well be about the only thing running on it. You can run other apps of course, but it is a compromise. The same is true of pretty much any other high end player as well, A+, HQPlayer, XXHigh End, etc.

Few people own a computer solely dedicated to a single task. The strength of computers is that they can do many things.

I doubt JRiver would say that the program is intended to be the only program running on the computer.

 

If it did the same job, no. But it doesn't, and yes, it is smart to move up to 64bit processing now and be prepared to handle computers that routinely come with terabytes of memory. It isn't that far in the future.

The computer is always playing uncompressed audio from memory unless you are bitstreaming. The only difference is whether you decompress the whole thing at once with a lot of CPU usage, or do it in small chunks that consume an insignificant amount of CPU time during playback. So it is doing the same job.

 

Considering that the memory playback feature had audible glitches for several months with tracks that exceeded the 1GB buffer, and no-one on here seemed to notice, I don't think anyone would hear a difference between storing the tracks in their native format or uncompressed.

 

It's amazing the things which people claim to hear on these forums, yet they somehow miss real problems like that.

 

I cannot understand why JRiver "caved in" and made this change, since their stance has generally been "bits are bits" and they still don't consider the memory playback option to be a quality feature. If it's not a quality feature, and it makes playback more susceptible to interruption (the opposite of every other program with this feature) when what exactly is it supposed to do, except inflate the amount of RAM the program consumes?

 

 

Personal computers have been limited to 32GB for years now, with many designs being limited to 16GB.

You're crazy to think that music playback needs anything like that amount of memory, or if you seriously believe that personal computers will be using 32x as much RAM in the near future.

It's true that DDR4 is going to be increasing this limit with 16GB DIMMs, but that is not going to be cheap, and there are still no consumer platforms using it yet.

 

JRiver uses a tiny amount of memory for music playback with the memory playback feature disabled.

 

Moving to 64-bit breaks a lot of features and compatibility. It will probably happen eventually but there is no need for it.

 

Only if you assume I am converting the album from DSD to PCM, which is something I just wouldn't do. I almost certainly would do the opposite though, and in fact, I do convert PCM to DSD for playback. If I really wanted to play it as PCM, I would convert it offline though.

When you have a lot of hardware devices which all support different formats, some supporting native DSD and others not, it would double or triple the amount of disk space required if I did offline conversions for each device.

I use JRiver because it is supposed to be able to handle this.

 

Even if you are bitstreaming DSD, DST compression can use quite a bit of CPU power.

 

I honestly do not know where you are getting these numbers from- I can decode and re-encode a file much much faster than that, so I think your numbers are a bit off.

A 20+ minute, six-channel, DST-compressed SACD track? (all multichannel DSD should be DST compressed in its original SACD/DFF format)

 

Well, yes and no. That PCM has to be decoded before it is buffered and sent to the DAC.

Decoding PCM is trivial. Stereo 24/192 tracks use <0.1% CPU to decode on my computer.

There is essentially no difference in CPU usage between using memory playback or not with PCM. If anything it seemed to be slightly higher.

 

The only thing memory playback does for PCM is increase the amount of memory the program uses, and cause there to be higher CPU usage in the middle of a track if it doesn't fit into RAM when uncompressed.

 

If they stored the native format rather than uncompresed audio, and stored multiple tracks in RAM (you could fit half an album of high res FLAC into 1GB) then memory playback would be a useful feature for eliminating disk/network access during playback instead of a placebo or a detriment.

 

The network queuing algorithm in JRMC is suboptimal, I will grant you that. It causes and is susceptible to packet queuing delays, which cause what you describe as latency. However, NAS that are not predictive and power down when they should not, networks too congested to reliably transfer traffic in a timely manner, and/or computers that are memory limited and depend upon weak processors are not something the J. River can be blamed for.

No, but it is something they can design against.

Which would you rather see, A or B?

 

1A) 1 track of 24/192 decoded into memory, taking up 700MB of RAM, using 0.1% CPU activity, with 20 seconds to buffer the next track.

1B) 4 tracks of 24/192 stored in its native format in memory, taking up 700MB of RAM, using 0.1% CPU activity, with no disk activity relating to the current track, and 10+ minutes to buffer the next track.

 

 

2A) 1 track of DSD partially decoded into memory, taking up 1GB of RAM, using 100% CPU activity every few minutes, buffering several times during a single track, with 20 seconds to buffer the next track.

2B) 2+ tracks of DSD stored in their native format, using up to 1GB of RAM, with a constant low-level of CPU activity, no disk activity relating to the currently playing track, with 5-10 minutes to buffer the next track.

[kbkaran]

@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.

[Paul R]

First and foremost, the feature should prevent interruptions during playback.

Whether or not it improves audio quality should be a secondary concern.

 

Maybe to some, but that hardly flies with the Audiophiles - who tend to believe that audio quality trumps pretty much everything else. I don't agree with that, but there are a lot of people who do.

 

Since all lossless and uncompressed formats should sound the same, it should have no effect on quality.[/Quote]

Again, an unfounded assumption. All bit perfect players should sound the same too, but they rather obviously do not. Same with amplifiers, CD players, etc.

 

Few people own a computer solely dedicated to a single task. The strength of computers is that they can do many things.

I doubt JRiver would say that the program is intended to be the only program running on the computer.

 

The computer is always playing uncompressed audio from memory unless you are bitstreaming. The only difference is whether you decompress the whole thing at once with a lot of CPU usage, or do it in small chunks that consume an insignificant amount of CPU time during playback. So it is doing the same job.

 

Considering that the memory playback feature had audible glitches for several months with tracks that exceeded the 1GB buffer, and no-one on here seemed to notice, I don't think anyone would hear a difference between storing the tracks in their native format or uncompressed.

 

That was a long time ago, no memory player glitches in v18, v19, or v20, if memory serves me correctly. It just plays and plays.

 

It's amazing the things which people claim to hear on these forums, yet they somehow miss real problems like that.

 

I cannot understand why JRiver "caved in" and made this change, since their stance has generally been "bits are bits" and they still don't consider the memory playback option to be a quality feature. If it's not a quality feature, and it makes playback more susceptible to interruption (the opposite of every other program with this feature) when what exactly is it supposed to do, except inflate the amount of RAM the program consumes?

 

Well, you do have valid points here. I suspect they did it to please the audiophile segment of their market. The very *vocal* audiophile segment.

 

Personal computers have been limited to 32GB for years now, with many designs being limited to 16GB.

You're crazy to think that music playback needs anything like that amount of memory, or if you seriously believe that personal computers will be using 32x as much RAM in the near future.

 

Sez who? Mine certainly isn't, the music player machine (an Apple Mac Mini) is limited. But - go back to 1999 and try to convince *anyone* that a music server machine would need or could even make use of 16GB of RAM? That's only 15 years ago, not a very long time at all.

 

It's true that DDR4 is going to be increasing this limit with 16GB DIMMs, but that is not going to be cheap, and there are still no consumer platforms using it yet.

 

It will get cheap, like it always does. I remember paying hundred of dollars for 640k of RAM. Not even a megabyte...

 

 

JRiver uses a tiny amount of memory for music playback with the memory playback feature disabled.

 

Moving to 64-bit breaks a lot of features and compatibility. It will probably happen eventually but there is no need for it.

[/Quote]

 

Drivers breaking is always the fault of the driver writer. Both Windows and MacOS put out developer version of they OS's just so developers can avoid having the products break in new releases.

 

Do remember that even running JRMC on a 64 bit OS is a plus- as the OS will use all available memory to buffer disk access, providing exactly what you are asking for. In other words, turn memory play *off* in JRiver and you get exactly what you are asking for. Those who can and do hear a difference when memory play is on or off can choose whichever setting they prefer. To me, it makes a difference I can hear, so I use it. If they move to full 64 bit compatibility, it will probably be just in time for everything to break going to 256 bit addressing....

 

When you have a lot of hardware devices which all support different formats, some supporting native DSD and others not, it would double or triple the amount of disk space required if I did offline conversions for each device.

I use JRiver because it is supposed to be able to handle this.

 

Even if you are bitstreaming DSD, DST compression can use quite a bit of CPU power.

 

A 20+ minute, six-channel, DST-compressed SACD track? (all multichannel DSD should be DST compressed in its original SACD/DFF format)

 

Decoding PCM is trivial. Stereo 24/192 tracks use <0.1% CPU to decode on my computer.

There is essentially no difference in CPU usage between using memory playback or not with PCM. If anything it seemed to be slightly higher.

 

The only thing memory playback does for PCM is increase the amount of memory the program uses, and cause there to be higher CPU usage in the middle of a track if it doesn't fit into RAM when uncompressed.

 

Well, that's your opinion. Many people disagree.

 

If they stored the native format rather than uncompresed audio, and stored multiple tracks in RAM (you could fit half an album of high res FLAC into 1GB) then memory playback would be a useful feature for eliminating disk/network access during playback instead of a placebo or a detriment.

Exactly what you get with memory play turned *off*. Best of both worlds for you?

 

No, but it is something they can design against.

Which would you rather see, A or B?

 

1A) 1 track of 24/192 decoded into memory, taking up 700MB of RAM, using 0.1% CPU activity, with 20 seconds to buffer the next track.

1B) 4 tracks of 24/192 stored in its native format in memory, taking up 700MB of RAM, using 0.1% CPU activity, with no disk activity relating to the current track, and 10+ minutes to buffer the next track.

 

 

If more than 5% of program code is devoted to catching obscure errors, or 10% in total, then the program probably is poorly designed. At least, that has proven true in all my experience.

 

-Paul

[Skeptic]

@Skeptic - looks like you want people/JRiver to accept your design idea of keeping data compressed in memory.

It's how things used to be. And performance used to be good before.

A return to storing compressed data would bring better performance, use less ram, and allow for more tracks to fit into the same amount of memory to ensure that playback is completely immune to interruption. It's better in every way.

 

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.

This is easy to test if you have a license for v18 (compressed audio) and 19 or 20 to compare. (uncompressed)

 

If you have memory playback turned on you are an audiophile and now we are in a different discussion.

It should first and foremost be a performance feature where you trade memory for better performance. (i.e. immunity to slow I/O)

That is the whole point of memory playback. It's not supposed to be a quality option, though "audiophiles" seem to think that it should be.

 

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.

Memory Playback in JRiver has CPU usage whether it is on or off.

If it is on, you have 100% CPU usage every few minutes during playback.

If it is off, you have around 1/10th the CPU usage constantly.

 

100% CPU usage every few minutes is disruptive, to the point that it can actually interrupt its own playback on slower systems with small hardware buffers.

 

That was a long time ago, no memory player glitches in v18, v19, or v20, if memory serves me correctly. It just plays and plays.

It was broken in v19 until 19.0.90 several months after release. And apparently no-one here noticed.

This was an actual problem, compared to the imaginary problems that people seem to think memory playback is supposed to solve.

 

Sez who? Mine certainly isn't

Intel's consumer CPUs are limited to 32GB.

 

Do remember that even running JRMC on a 64 bit OS is a plus- as the OS will use all available memory to buffer disk access, providing exactly what you are asking for. In other words, turn memory play *off* in JRiver and you get exactly what you are asking for.

...

Exactly what you get with memory play turned *off*. Best of both worlds for you?

You seem to be misunderstanding the problem, and/or how playback in JRiver works.

 

Again, 64-bit breaks a whole lot. It breaks VST plugin support and video playback completely. Input plugins for at least some of the audio formats are probably affected too.

 

As an example, dBpoweramp are still ironing out bugs from their switch to 64-bit. I've only used it to convert between FLAC and ALAC and already had to report several issues. Switching to 64-bit is not a trivial thing for something as complex as JRiver, and it should not be necessary at all if they use their available memory more efficiently.

 

Switching to 64-bit so that the program can use almost 14x as much RAM to perform the same task is ridiculous.

[tranz]

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!

[kbkaran]

Memory Playback in JRiver has CPU usage whether it is on or off.

If it is on, you have 100% CPU usage every few minutes during playback.

If it is off, you have around 1/10th the CPU usage constantly.

 

100% CPU usage every few minutes is disruptive, to the point that it can actually interrupt its own playback on slower systems with small hardware buffers.

 

 

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.