XXHighEnd

I can't believe no one has mentioned this yet.

Peter, you said this regarding 0.9u-7:

I interpreted this to mean that large tracks (such as a single WAV file for a whole album) would be too large to fit into memory. But as it turns out, by not checking 'Mem', each track accumulates onto the previous track (as far as the amount in memory). And, since I am checking 'double', the amount of memory used is huge. After 4 songs it is already as large as 800MB. So suddenly our playlists have to be very small.  :wacko:

I understand for gapless to work, two songs have to be in memory at the same time, but is it not possible to clear the previous song out of memory after it has moved on (instead of accumulating)?

Are you sure it keeps on accumulating ? I mean, you shouldn't look at just 2 subsequent tracks, but just "all" of them. Also, it's more complex than just two tracks being in memory at a given time, but never mind that, as long as you don't calculate wrongly.

If you have tracks of, say, 100 MB each, you can run them forever. But if you can prove it cannot, please say so.
Here it's no problem ... :dntknw:

Well, I have Task Manager open with the Processes tab selected and under the Memory column I can see, after playing 4 subsequent tracks, the amount of memory is over 750MB and when it runs out of available memory XXHighEnd crashes.

Do you need to see a screenshot? Or how else would you like me to prove it? And FWIW, in addition to the settings you see in my sig, I'm also using volume control.

But wait a minute ... You aren't telling you are using 1GB of memory only ? or ?

Well . . . I didn't think it was relevant. No matter if it runs out at 5 songs or 10 songs, it still accumulates and runs out.

But, FWIW, I have 2GB of RAM, but 900MB is dedicated to my RAMDisk. I was going to change the RAMDisk to 1.3GB to accomodate 2 CDs worth of music, but perhaps I need an additional 2GB of RAM before I do that.

Well, so virtually you are using 1GB. That can't work ...
FYI, when I run things in the Double/Preprocessed mode, I have a rather constant just over 1GB of memory in use (including Vista and all). This does NOT accumulate. It does for the first few tracks though, and how is too difficult to explain.
Maximum I saw was 1.7GB with a 23 minute track, BUT, this was preceeded and followed by "normal" 6 minute etc. tracks. Two subsequent tracks of 23 minutes 100% sure wouldn't have fit.

So again, if you say it accumulates (btw implying a "memory leak"), please prove that. But better don't, because first you must have enough memory to prove it, and 1GB is not that.

About our discussion long ago : the RAM disk IMHO does nothing more than disturb you, *unless* it can cause all the disks to spin down. So when the latter is in order, I'll say nothing. But if the disks keep on spinning anyway, you are just adding another layer of memory, and you shouldn't. Keep in mind that XX already plays from memory 100%.

And I know, I once promised to look into spinning down the disks myself, of which I'm sure it can be done but not in in easy way (I looked into that some time ago).

Ok ?

I will turn off my RAMDisk tomorrow and play with the full 2GB to see how it goes. Until then . . .  :sleeping:

Maybe you can understand it a bit if I explain it like this :

a. The file is read into memory;
b. From memory it needs expanding to 32 bits. For 44.1/16 that's now three times the data;
c. For gapless the next file needs to be read into memory. Note : a. is deleted by this time. This is still three times now.
d. b. repeats. That totals to 5 times.

With 24 bit files it's a little different (1/3 is added) but the files are bigger to begin with.
With 96KHz files all is again bigger to begin with.

Roughly you can say that 3.5GB is needed now for two subsequent tracks that comprise of a full CD. It's slready hard to find even one of those (but they do exist, like Amarok from Mike Oldfield), so it's all not that bad. Also, for the exceptional situation of subsequent tracks being large (and two 20 minute tracks would be that) the Mem checkbox is there.

But cutting down the memory to 1GB ...:nea:.
You should have 2GB available, as the "specs" say. And yes, officially the specs should change now (with the additional preprocessing), but I'd rather use the Mem checkbox. Also keep in mind that not all 32 bit OSes will recognize over 2GB of memory (AFAIK).

So ...

Oh, I forgot. When Double is in order, multiply the expanded part by two. Mentioned "three times" is now five ...
Do I need to explain about Quad ?  :blob8:


I know it's crazy.

How much RAM do you have Peter? Even with my 2GB, I barely have just over 1.6GB available (IOW about 85%) to run XXHighEnd.

Anyway, I disabled my RAMDisk and sat down for a session with Tears For Fears (Songs From The Big Chair). There are 16 tracks and here is what happened as far as memory goes:

1. 6:33 -- 355MB
2. 6:31 -- 626
3. 4:12 -- 844
4. 5:07 -- 1109
5. 4:55 -- 1364
6. 2:38 -- 360
7. 5:02 -- 390
8. 6:57 -- 750
9. 2:09 -- 420
10. 4:18 -- 332
11. 2:50 -- 345
12. 3:35 -- 323
13. 3:43 -- 361
14. 2:26 -- 301
15. 3:50 -- 321
16. 5:17 -- 453

So, the first number is the track length and the second number is the amount of memory Engine3 was using when that track started. It did play all 16 tracks without running out of memory. Interesting how it went all the way up to 1.3GB and then seemed to go back to normal. So . . . do these numbers look normal to you Peter?

But wait, there's more. I did have a few issues. It took until the third try to play all the way through. The first time it stopped after the 6th track and gave me the message "Engine #3 did not start within the expected time!". The second time it stopped after track 15 (same error message). And my other issue is all the crackling. There was a fair amount of crackling (static noise) but it was random - only a few songs. But if I stopped and went back and played those tracks individually, then there was no crackling. (It was only when playing the entire playlist) And now for my final issue, the gapless was not always so smooth. This appeared to be as random as the crackling. What would happen is there would be the opposite of a loud pop (like a split-second of silence) that sounded like a record skipped and it would happen right at the time the next track was loading into memory (probably about a second or two before the end of the previous track).

Sorry to dump all this on you Peter. FWIW, I tried with and without volume control and checking or not checking crack detect - same results.

And finally regarding:

I know we've had lengthy discussions about this and I don't need to "hash" it out again. In fact I would prefer not to discuss *opinions* with you or anyone else for that matter until you have tried it yourself.  ;) I understand the theory that a RAMDisk should not matter and I don't have any science or measurements to back me up, but my wife and I have performed blind tests many times (including tonight for good measure) and I 100% of the time can identify whether I'm listening to the RAMDisk or my HDD. But even your statement that XX already plays from memory 100% is not entirely true unless you are only referring to as of 0.9u-7. You yourself have said that previously there was a fair amount of "real-time" activity. I am a big fan of pre-processing and getting it ALL into memory before it plays. But now the problem I foresee is that Vista (32bit) will only recognize 3GB. "We're going to need a lot more gigawatts for the flux capacitor!" What happens when Reference Recordings releases their 24/176.4 files and then other labels follow suit?

Wow, you have been busy ...

Let's start with the end : No, everything is 100% from memory, and it always was (each Engine). You may not have expected it, but the "real time processing", is still processing things from memory only. Of course you are not used to it, but since you play without the RAM disk now, look at the disk light ...
There is no single way "playing" from the RAM disk can make a difference. BUT : As you know many other influences play a role, like the spinning disk (or not) and probably the part of memory which is used. So indirectly you can be right (no, will be right because you say you hear it), but this is unrelated to the "playing" as such from the RAM disk. You might just as well fake the lot by copying another album to the RAM disk than you play from e.g. a memory stick (which may sound different again because of using the memory stick).

The list looks normal to me, yes. On the first couple of tracks and mem useage, keep in mind that physically freeing memory is out of anyone's control in the .NET environment, and that the OS decides when to free the memory. At your 1.3GB it apparently thought "this is enough", and that will have happened at the stage of loading the 6th track. Note that this track temporarily needs more than just that track, like the 30MB it would be on disk, needing 30MB for the file + another 30MB + whatever it took for "processing"  after which the first 30MB gets deleted. This takes a few tenths of a sec only, and you won't have noticed it. Of course if the OS doen't throw it away physically, it would add up (like with the first tracks).

I too have 2GB, and it is enough for normal "operation". Indeed Vista takes some 400MB at least, which can easily grow to 800MB "permanently" for the boot session (in my case anyway).


So far these kind of things have bugged me always, and with all Engines (which are all so totally different that there can't be a relation). Everybody will have this. BUT :

Is it a coincidence that you mention this for the first time ? I think not. Why ? well, expecially because the only reason I could find throughout time is that this is hdd related. For me it always has been so that "something" happens within the first couple of tracks, which does not happen anymore lateron. And mind you, I'm talking some 500 days = times by now. It's standard. To me it looks like the hdd spins down rather "hard" (and earlier than should) after a first wakeup - after a longer sleep. :wacko: I don't know.


This is something you can get experienced on (judging it to the real merits) once you first have the "trust" that it's not the program doing it (and I obviously can have that trust). Over time I learned that this is very easy to "see" once you watch the behaviour of the OS closely. An easy one is the OS shutting down a service, which most often goes along with a message saying so. Leave that message be, and you'll get crackling. But now what, when there is no message ? In my case, most often buttons change (and back), but you already have the W3.11 buttons, and they won't change back.
I know, this sounds a little like voodoo (especially to newbies here), but I really can see it coming. But man, there is MUCH more to this;

I am as far that I can "see" on this (behaviour of the OS) how accurate playback is (if accuracy on this matter may emerge from sending out the bytes software wise). Now first look at your own case : you changed from playing (!) from RAM disk to normal hdd and your OS starts to behave differently. Mind you, this can be impeeded by the prio settings (and IMO it should). So, where normally nothing bugged you (or set your settings so it did not), now it suddenly does. Look at the difference between playing 44.1 and 96, where the latter requires more. It may well happen that at the moment you switch to 96, the OS shuts down a few services (I know, not in your case where you already did that yourself).
My case from yesterday : I changed something again, with the objective of better sound. Well, apart from that I was crying over stupid Billy Cobham tracks (so yea, it worked), all kind of strangenesses happened throughout the hours of playing. One of the most important : the reading / processing of a next track stalled playback during that time (0.5 - 1 sec). What I think with this : the playback is now so much persistent (and looking at the software I can "see" that), that it destroys proper time slicing and once the "reading" thread becomes alive, it won't give away until finished.
And the only thing I did was changing the code a little, and really nothing explicit (but on purpose, which is something else).

Is all of the above the answer to your crackling ? Yes. Apparently you never noticed it, but you changed the means of playback and now things don't workout anymore. Btw, I think 50% of people experienced the crackling, which they in 95% of cases attacked by the wrong means (like changing Q1, Priorities). I say it's only a matter of let the OS settle with the services, some means to enforce that, and looking at it in a way actually nobody can. So it's not easy.
For me though, it is 100% sure that once you did not have crackles, but it starts, you just have to wait until things settle. This *always* goes along with Stop/Start, because once it happens, it won't go away by itself (and the waiting is a matter of seconds).


So this is what I was just telling about myself. I never had that before though, and you don't have that software version. There are just more ways leading to Rome (well, away from it, this case).

:)

Edward,

After rather extensive paying attention tonight, I noticed that Attended playback actually doesn't play gapless anymore.
Also, the one time I experienced a small click (which was at Unattended), this came a long with a disk I/O (amongst other disk I/O's).
This is a tough one ...

I think I should mention here (I think I already mentioned in another thread) that ALL plays correctly when I check 'Mem'.

And as far as disk I/O, FWIW I re-enabled my RAMDisk and made it just large enough to fit 7 tracks and still small enough that I don't run out of "actual" memory. In this situation, I still have all the issues I mentioned in my previous post, so I think your theory of things going wrong for me when I changed my playback method is not valid. (At least not entirely).

But I have not been able to try 0.9u-10 yet.

BTW, when you speak of "along with a disk I/O" are you referring to a Vista invoked I/O or an XXHighEnd invoked I/O?

Thank you for mentioning this. I wasn't aware of it, although it is something which could be expected. Now, however, I can start looking for the differences explicitly.


Accepted and appreciated !


I know it is important, but I didn't know how to express it better. It would be an XX invoked IO;
Maybe you recall that I anounced that my own system started to act weird because of the playback now being more "persistent" (as how I explain it). This click too - when I am right that this comes along with an I/O (just one small blink) - makes me think that indeed time slicing isn't working properly anymore (or hmm ... maybe I should lower the prio now, which is at real time). The attended playback not being gapless is another indication of that. Note that in the Attended case the files are fed by XXHighEnd. I've been looking at 10ths of tracks, and it now just starts doing that when the playback from XXEngine3 is finished. And they're both unrelated !!

It's also a good reason why for the life of me I can't find anything wrong in the code.

But I think I can try some new things, with your last post in my hand. Thanks.

Btw, you needn't try 0.9u-10 for these things.