Print

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

[AlexS]

Hi

I'm sure some components are already 64 bit but I was wondering why JRiver gets installed in Program Files (x86) folder by default?
Are there still 32 bit components?

Thanks

Alex

(Windows 7 64 bit).

[mojave]

JRiver Media Center is a 32-bit program. Most or all 32-bit programs installed on a 64-bit Windows are installed in the Program Files (x86) folder.

This is completely different and not related to the processing within JRiver which is done with a 64-bit data path.

[AlexS]

Are there any plans for a 64 bit build?

Thankyou.

[glynor]

While some things have changed since this thread, mostly we're still in the same place.  There is very little to be gained from MC going 64-bit fully.  It would make memory usage balloon, and would provide very limited performance benefits.

If MC19's memory usage is running higher than 4GB, then something is badly wrong.  If you have more than 2.1 million files in the Library, then I guess the larger integers would help.  For the rest of us, it would just make the memory allocation for all those ints used in the Library twice as high.  Seems like a poor tradeoff.

[6233638]

If MC19's memory usage is running higher than 4GB, then something is badly wrong.  If you have more than 2.1 million files in the Library, then I guess the larger integers would help.  For the rest of us, it would just make the memory allocation for all those ints used in the Library twice as high.  Seems like a poor tradeoff.

Currently Media Center is limited to around 1GB of memory, so removing that limit could help. I believe it could be raised to 3GB on a 32-bit OS, and 4GB on a 64-bit one.
 
With the way MC19 uses memory compared to MC18, I feel that a 64-bit build could now be beneficial though. With the changes made in MC19, it is unable to completely cache songs now, and is susceptible to high disk/network activity causing problems with playback.
With DSD tracks, I always get a slight skip/tick on every track, usually somewhere between 50-75% through, whenever memory playback is enabled. That did not happen in MC18, nor does it happen if I disable memory playback.
 
Of course, rather than moving to 64-bit which allows access to more memory, but also causes the program to use more memory, and breaks compatibility with a number of features, increasing the cap to 3-4GB, and bringing back the option to cache files rather than decoded audio would probably be enough.
 
I'd still really like to see the option to cache the current and next track, rather than only the currently playing one - that gives Media Center the full duration of a song to cache the next track, which would be useful when there's a lot of disk activity.


I like a lot of the changes we have seen in MC19, but there are serious regressions with the new memory playback system which I feel really need to be addressed.

[Matt]

Currently Media Center is limited to around 1GB of memory, so removing that limit could help.

The limit for a 32-bit process that enables large page mode (which we do) is a bit over 3GB on Windows.

[JimH]

It would be nice if people who don't understand what 32 bit means on an OS would not make sweeping statements that may confuse others.

[Matt]

MC is compiled as 64-bit for OSX.  This means the code is ready.

But I don't expect a 64-bit version on Windows for a couple years.  The current model of a single installer that's 32-bit with some 64-bit parts works well.  Glynor's explanation above gives some technical justification.

In short, there's not much to gain yet, but there is a bit to lose in terms of performance, plugin compatibility, and simplicity for users.

[InflatableMouse]

Besides, 64-bit is actually slower than 32-bit code, with the exception of some specific stuff.

http://www.pcstats.com/articleview.cfm?articleID=1665

Whether we'd notice that in MC I don't know but I'm sure some people will find reason to complain  .

[Hendrik]

Besides, 64-bit is actually slower than 32-bit code, with the exception of some specific stuff.

http://www.pcstats.com/articleview.cfm?articleID=1665

Whether we'd notice that in MC I don't know but I'm sure some people will find reason to complain  .

That article is 9 years old, on the first CPU that supported 64-bit, and developers who didnt have any experience with it yet, do you really think thats representative?

64-bit code can generally be faster (but doesn't have to be), how much is another question. More memory isn't the only thing it offers. :p
Media Center does a lot of DSP operations, image processing, audio/video decoding/processing. Those things can be quite a bit faster in 64-bit.

But does this additional performance out-weigh any other factors? Probably not yet.

[Matt]

Media Center does a lot of DSP operations, image processing, audio/video decoding/processing. Those things can be quite a bit faster in 64-bit.

The audio engine is floating point, and the image engine is SSE, so I wouldn't expect too much gain there.

Memory movement is already SSE/AVX.

64-bit offers more registers, so sometimes general code gets a little faster (say 5%).  Sometimes this is offset by the increased size and sometimes not.

Are there bigger gains somewhere I'm missing?

[glynor]

64-bit code can generally be faster (but doesn't have to be), how much is another question. More memory isn't the only thing it offers. :p

Right, and please don't take my discussion as suggesting that this isn't the case.  It most certainly is true, and there are plenty of applications that can benefit (occasionally dramatically) from a 64-bit version.  I just don't think the benefit here would be huge.

MC is compiled as 64-bit for OSX.  This means the code is ready.

That's cool.  I expected as much, of course, but I didn't know if you'd pulled some dirty tricks to get it working.

[InflatableMouse]

I know that article is old, but I've not seen anything newer suggesting things have changed.

That article clearly shows some huge improvements in some areas.

I'd be interested in seeing benchmarks showing significant changes to what was tested there.

[glynor]

showing significant changes to what was tested there.

Well, one significant change has been, of course that we now have far less pressure on our memory subsystems (faster RAM, and way more of it).  The penalty for the increased memory cost is much lower than it once was.

And, as Hendrik suggested, we have collectively had much more time to learn and develop on the hardware (things that work, things that don't, patterns to follow and anti-patterns to avoid).

[AlexS]

Having a 32 bit build and a 64 bit build allows the user to make the choice, end of debate...

[Hendrik]

The audio engine is floating point, and the image engine is SSE, so I wouldn't expect too much gain there.

With double the number of SSE registers to be used, you can usually make code faster in 64-bit, assuming a certain level of complexity.
This doesn't work for all code, and its not totally obvious when using intrincs since it hides register management from you, but it can make stuff go faster.

Anyway, as Matt said earlier, the time isn't right yet because of complexity/compatibility concerns. We'll keep revisiting this topic in the future, and when we decide to offer a 64-bit Windows version, you all will be the first to know!