Print

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

[dtc]

WIth the new memory playback, I have a few questions about how it works. (I know, it works great).

Is there any way to find out how much memory is being used for memory playback? Could that size be added to either Audio Path or the dsp display page?

How often is the memory being used changed? Is it just on startup of MC or does it change while the program is running?

How often does the memory get filled? Is it on a continuous basis or does it wait until it reaches a certain level (like 20% full) before it fills again?

If I understand correctly, when playing compressed files (flac), the compressed data is loaded into memory and decoded after it leaves memory. Is that correct?

Any insight would be appreciated.

[Audioseduction]

This would be nice to know. 

[Blaine78]

I don't know about memory usage for memory playback, but as for FLAC, it sends the compressed FLAC to memory and decompresses it on the fly... check my thread here

http://yabb.jriver.com/interact/index.php?topic=68005.0

[Maxxwire]

I had the same question myself about how much memory JRiver Memory Playback was using and so I used Sysinternals Process Explorer and took a pair of screen captures showing first without and then with using Memory Playback of the Music I have stored on my Win 7 x64 computer's Intel 320 SSD...

[Vincent Kars]

I don't know about memory usage for memory playback, but as for FLAC, it sends the compressed FLAC to memory and decompresses it on the fly... check my thread here

Assuming the output buffer of MC contains fully decoded audio, say what is send to the DAC, a nice experiment would be to be able to set the output buffer to 1 Gb.
Then we have true memory playback.

[dtc]

Can another from J River provide some information on memory usage? If it is proprietary information, I understand. If not, I think it would be interesting to know some of the details. Adding a display of current usage would also be nice. Anyone?

[glynor]

Can another from J River provide some information on memory usage?

I don't know if anyone knows what you are asking for, and certainly not why...

That's what Process Explorer is for, if you need to know memory usage details.

[Matt]

The graphs posted by Maxxwire above are really neat, and show perfectly the difference between memory playback and normal playback.

Thanks for posting them.

[dtc]

I don't know if anyone knows what you are asking for, and certainly not why...

That's what Process Explorer is for, if you need to know memory usage details.

I assume that the development team knows the answers. Maybe not, if they are just using some black box services.  Sure, people can invest time and effort into looking at the memory usage. But, a brief explanation would also be useful, especially given the recent update to the memory playback feature.

Why? Because it is interesting stuff to know. It is not necessary to know - just interesting to know. On other boards these types of issues are discussed, whether you believe the analysis that people propose or not. Mostly I am pretty skeptical of most of that analysis, but knowing now MC worked would be helpful to put those discussions in perspective.

[JimH]

It's not possible to provide all the details on how the program works.  In this case, up to a GB of memory can be used, but there is a sanity check against available memory so that Windows doesn't need to write to disk.

[glynor]

I assume that the development team knows the answers.

It's not possible to provide all the details on how the program works.

That was effectively my point.  I meant, no one knows precisely what you are looking to know.

Your language in the original post was very non-technical, but you are asking for technical details.  "How often is the memory changed?"  What does that even mean?  The application cannot, obviously, physically swap out your RAM sticks on the motherboard, but that's the only thing I can think of that would fit a generalized "change your memory" type of description.

If you are looking for very precise technical details, and have a specific reason why you are asking, I'd suggest that you ask the developers much more targeted questions.  If you don't understand how C++ development works in detail, and you are asking generalized questions because other people who don't know what they're talking about on other forums are discussing these things, well then...

If you really care, then I'd suggest you learn about how memory allocation in C++ works.  O'Reilly makes a nice line of books on the subject.

[dtc]

Sorry I was not precise enough.

My initial questions came about because I thought MC might be allocating a fixed amount of memory at startup and filling that on an on-going basis. Or maybe allocating memory for a given album or playlist and changing that allocation for different albums and playlists. That does not appear to be the case.  MC does not try to determine how much physical memory is available (up to 1G now) and load multiple tracks to fill that memory.

Here is a simple explanation of what is going on, as I now understand it. If I am incorrect, please let me know.

MC loads a single track into memory at the beginning of each track. It appears to just dynamically allocate and de-allocate memory (as C++ normally does) as needed between tracks. It does not load multiple tracks, even if there is enough memory available to do that.

If the track is larger than it can allocate, it loads what it can and reloads the rest of the track when necessary. Since I do not have a track large enough to fill the new 1 G limit, I cannot test how it handles a large track, but it is also not relevant for the vast majority of tracks.

MC does not set a fixed block of memory aside and keep that filled. That would be an option if you wanted, for example, to pre-allocate memory to be sure you have it available. In that case, you could allocate a large amount of memory and pre-load all the tracks on most albums, for example, and not have to do I/O between tracks. It appears MC has elected not to do that.

Given that the memory allocation is simply the size of a track, there is no real need for MC to show how much memory is being allocated (it is just the track size -other than for extremely long tracks). 

One practical conclusion from this is that people with memory constrained systems should not rush out to get more memory because of the new 1G allocation, unless they have extremely large tracks.


glynor  -   I am just trying to understand the process. You may find that strange, but I see nothing wrong with being curious and trying to be well informed.

[MrC]

In all sincerity, if you want to learn about this stuff, start reading the Windows APIs for memory allocation, and then start developing an application to learn about how Windows allocates memory, how programs can and do use memory, how to understand things like heaps and stacks and pools, and how to correlate that knowledge with various diagnostic tools like debuggers, profiles, etc.

Otherwise, you're just messin' with the Fetzer valve.

[glynor]

glynor  -   I am just trying to understand the process. You may find that strange, but I see nothing wrong with being curious and trying to be well informed.

I don't find it strange.  I was just pointing out that the reason you weren't getting the answers you were looking for was that, at least in-part, your question was very poorly framed.  That's why I asked "why" do you want to know this.  Not because I was going to tell you that what you were asking was dumb (well, maybe, but probably not), but because it would help them to understand the question itself better.

Your most recent post reveals the root of what you were looking for, which was "Does MC pre-allocate just the current track, or does it pre-allocate memory for all tracks in the current Playing Now list?"

The answer is "just for the current track".  And, yes, that's because the Playing Now list could be of effectively infinite length and the RAM usage could get unreasonably high extremely quickly and cause Windows to start swapping (which would defeat even the voodoo purpose of RAM playback).  Matt explained just recently in another thread more precisely how and when they decide to load the next track from disk (which is, I believe, just before the previous track finishes playback).  That's also because MC tries to be very resource-light, which is why it runs so fast and beats applications like iTunes to a pulp in speed testing.  There is no point in allocating a huge amount of RAM for things you might not use for another hour or more.

Now, on the other hand...  If you are RAM limited, there is no better reason to get more than the fact that RAM is absurdly cheap right now.  Here's 16GB of high-quality RAM for $75 from Amazon, and there is even a $20 mail in rebate on it available.

[dtc]

In all sincerity, if you want to learn about this stuff, start reading the Windows APIs for memory allocation, and then start developing an application to learn about how Windows allocates memory, how programs can and do use memory, how to understand things like heaps and stacks and pools, and how to correlate that knowledge with various diagnostic tools like debuggers, profiles, etc.

Otherwise, you're just messin' with the Fetzer valve.

With all due respect, I do know about all those topics and I used to teach them in classes on operating system, data base design, real time device drivers and the like. I wrote real time applications and database applications for a living. My first exposures to these topics was from Knuth's seminal works - not an easy taste because you had to know MIX to read them. I wrote memory allocation code in assembler before C++ was a common language. I first learned about  PC memory allocation on DOS version 2.  So, I do know all those topics, although it has been a few years since I practiced them on a daily basis. Clearly, I am not a youngster.

I was just looking for some simple answers, which I finally got for myself.

[rick.ca]

In all sincerity, if you want to learn about this stuff, start reading the Windows APIs for memory allocation...

I hope you're not serious. There's an option to use memory playback or not. Most users do not have a computer science background. Most of us don't have the aptitude or desire to get one. Yet we would still like to understand enough to know how to set this option—or whether or not it matters. "If you don't know, don't ask" doesn't cut it. If the purpose of an option is not self-evident to the average user and undocumented, it shouldn't exist. Topics such as this are often the only documentation available for such things, and the questions that start them should be encouraged.

I was just pointing out that the reason you weren't getting the answers you were looking for was that, at least in-part, your question was very poorly framed.

From a non-technical perspective, the question was not poorly framed. It seems the problem here is the more technically inclined reading more into the question than they should. In any such conversation, it's the responsibility of the better-informed to properly interpret the question, or to ask for clarification. He might have just asked, "Should I use this option?," but that may have resulted in no response, or "Why do you ask?"

[JimH]

As I said above, we can't describe the details of every feature. 

As E.B. White once wrote to a reader who had asked if he could visit, "Dear Mr. Ferguson, Thank you for your note about the possibility of a visit. Figure it out. There's only one of me and ten thousand of you. Please don't come. Sincerely, E.B. White."

[dtc]

I don't find it strange.  I was just pointing out that the reason you weren't getting the answers you were looking for was that, at least in-part, your question was very poorly framed.  That's why I asked "why" do you want to know this.  Not because I was going to tell you that what you were asking was dumb (well, maybe, but probably not), but because it would help them to understand the question itself better.

Your most recent post reveals the root of what you were looking for, which was "Does MC pre-allocate just the current track, or does it pre-allocate memory for all tracks in the current Playing Now list?"

The answer is "just for the current track".  And, yes, that's because the Playing Now list could be of effectively infinite length and the RAM usage could get unreasonably high extremely quickly and cause Windows to start swapping (which would defeat even the voodoo purpose of RAM playback).  Matt explained just recently in another thread more precisely how and when they decide to load the next track from disk (which is, I believe, just before the previous track finishes playback).  That's also because MC tries to be very resource-light, which is why it runs so fast and beats applications like iTunes to a pulp in speed testing.  There is no point in allocating a huge amount of RAM for things you might not use for another hour or more.

Now, on the other hand...  If you are RAM limited, there is no better reason to get more than the fact that RAM is absurdly cheap right now.  Here's 16GB of high-quality RAM for $75 from Amazon, and there is even a $20 mail in rebate on it available.

I guess I missed Matt’s previous post. It might have been in a thread I do not have access to. But I will take another look.

Even if the Playing Now list is long it is certainly possible to load a portion larger than a single track. Other players do. I was just looking for a comparison.

To be blunt, it was the “you are asking generalized questions because other people who don't know what they're talking about on other forums are discussing these things, well then...” comment I found a little pointed.

Since my questions seem to be answered, it is time to listen to some music.

[glynor]

To be blunt, it was the “you are asking generalized questions because other people who don't know what they're talking about on other forums are discussing these things, well then...” comment I found a little pointed.

I'm glad you got it figured out.  For the record, I was really NOT trying to be a jerk.  I honestly just didn't know how technically inclined you were, or what specifically you were looking for, so it was hard to know how to answer.

And then, a few replies later, it looked like you still weren't getting the answer you needed, so I figured I might bump it a bit to see if we could get more details out of you, so that you could get the answer you were looking for...  But, I added that line because we DO get a bunch of "voodoo" questions here (like "why doesn't it have more 64-bitness", for example).  I tried to put it as an either-or thing, not an assumption of your level of knowledge.  (That line you quoted was preceded with the word IF, and there was a whole sentence before it.)

That's all.  

[MrC]

Sorry dtc, I meant no offense either.

[dtc]

Thanks guys. We're cool.

[glynor]

I guess I missed Matt’s previous post. It might have been in a thread I do not have access to. But I will take another look.

I can't find it either and I'm tired of looking.  It was either Matt or JimH, and it went something like "J River believes..."

It was around the time of all of this stuff though, and posts were getting split and moved around like crazy.  But, in the post, they described how they decided to do the memory allocation, and how they believe it is generally really better to leave the memory playback stuff turned off, but that if you do "believe" in it, why it makes sense to do it the way they're doing it.  It was actually a very good sum-up, and I wish I could find it.

[Sandy B Ridge]

This thread?:

http://yabb.jriver.com/interact/index.php?topic=63609.msg426275#msg426275

From a technical perspective, why do you recommend not using it?

It uses memory and switches I/O from smooth (gradual reads while playing) to lumpy (full speed read at the start of a file).  It doesn't change the data that gets delivered to the soundcard.

However, there are plenty of users that disagree with my recommendation.  In fact, there are a few threads where users are requesting the ability to tune how memory playback is done (allocation size, page locking, etc.) to make it even better.

SBR

Edit: Whoops! Thanks Jim for moving it.

[dtc]

Thanks. Looks like that thread is for beta members only. But, I think I understand most of the issues. No reason to take this thread down that road at this time. That discussion is never pretty. We'll see how JPlay pans out. I am perfectly happy with MC.

[JimH]

I moved the thread.  You should be able to see it now.

[dtc]

Thanks Jim. Appreciated.