9-Z3

[Josef]

cPlay uses Address Windowing Extensions (AWE) to allocate RAM to music files during playback (Lock pages in memory).

Hehehe - you have not been paying attention to what I wrote above?

Large Pages is NOT the same as AWE: With AWE you still get fragmented memory! Not so here

To verify, I just downloaded cicsPlay.exe and I'm afraid it is as fragmented as any player - regardless whether it is in AWE or non-AWE mode...

PS
Why did you set affinity to 1?

Well spotted!
Mea culpa: I was playing with affinity settings and uploaded the wrong file - I have now re-uploaded it to the post! (it's now set to 2 as I only have a dual-core but you can of course change it)

As you very well know from your experiments affinity does seem to influence SQ and it also works with these tiny players: I'm just not 100% certain whether that registry setting works, however....
Maybe you can double-check on your 6-core audio-monster and let us know? 

[Josef]

jplay2 sounds better for sure 

Wow - that was quick indeed! (but coming from you I'd expect nothing less )
So, 0:1 so far, let's see if we can get some more opinions....

[manisandher]

I'll give this a go this evening. Really interested in hearing the difference...

Mani.

[Marcin_gps]

Josef,

Don't want to be picky, but shouldn't it be hexadecimal? (affinity)

[Josef]

Don't want to be picky, but shouldn't it be hexadecimal? (affinity)

?
It doesn't matter, does it?

[Marcin_gps]

I don't know :D I'm used to hexadecimal values as I spent much time with IRQ affinity tool...

[Josef]

I don't know :D I'm used to hexadecimal values as I spent much time with IRQ affinity tool...

You're getting geeky 
No, Decimal or Hex does not matter: what matters is how it looks in binary....

[manisandher]

Josef, wow! That is one clean sounding player! Well actually two, one of which is clearer better than the other. My strong preference is for JPlay2. And yes, as soon as another application is opened, JPlay2 struggles to play.

Marcin, Ivo (and many others I'm sure): yes you're all absolutely right - XX sounds much better when files are copied manually to RAM and then played directly from there, with 'Copy to XX...' and 'Don't Play...' left unchecked.

I compared XX Engine#3/Q1=0 (playing a file manually copied to RAM) vs. JPlay2. XX sounds fuller and more musical, but JPlay sounds cleaner. JPlay sits on my SSD c: drive, along with the OS. I tried to play it from my RAM drive, but couldn't get the command prompt to recognise the RAM drive.

Mani.

[All listening conducted on my Atom PC with RME AES-32, whilst my main PC is upgraded ready for the NOS1!]

[Marcin_gps]

Mani,

XXHE sounds more musical, because you use SFS.ini=21 and larger SFS. Set the SFS.ini to 00, SFS to 12 MB, Scheme-1 and try again You might discover the opposite. And make sure to manually copy the tracks to RAMdisk.

Cheers,
Marcin

[christoffe]

Mani,

XXHE sounds more musical, because you use SFS.ini=21 and larger SFS.

Hello,

you guys have really good ideas.
The SQ with the copied files to the RAM disc is superior.

Explanation for this phenomeon. Less jitter?

best

Joachim

[Josef]

Josef, wow! That is one clean sounding player! Well actually two, one of which is clearer better than the other. My strong preference is for JPlay2.

Eh, player was not meant to enter into competition with XX but rather establish whether RAM fragmentation can influence quality of music playback - However Mani, thanks for kind words! (btw I also find myself preferring it over XX in KS mode - weird...)

So, it's 0:2 now and I guess I can also give my score as cat is out of the bag now, which makes it 0:3.
I was hoping more people would post (like, ehm, Peter? )  so we could make this even stronger statistically (there's been 12 downloads by now).

But anyway, 0:3 is not that bad either and hopefully proves the point that RAM fragmentation can & does influence quality of music playback even though the code that is being executed as well as data streams themselves are both 'bit-perfect'.

Hopefully this ought to help everyone understand better the 'mysteries' of why various SFS settings and manual vs 'XX-Copy to disk' have an effect.
And I've certainly had some fun and also learned something new in the process - hope you did too!

[manisandher]

Maybe statistically a bit weak, but a phenomenal find nevertheless Josef. Thanks for sharing.

Mani.

[PeterSt]

I was hoping more people would post (like, ehm, Peter?  )

Yes of course, but you know ... I don't like A-B stuff in the first place, I'm quite busy with other (DAC) priorities at this moment, and I thought to accept the outcome anyway. Also, with that I don't like the A-B stuff, my outcome will not be reliable (I'd really need 5 days to listen to one situation, and another 5 to the other).

What I will do though, is incorporate it in 0.9z-4. In fact, I already believed in it before you started this (great work and great thanks btw !). Now all I need to find is something which mimics that copying. My current means apparently doesn't cut it, but what will ? If someone could tell me *that*, I'd build that in instantly as well. Could be a simple copy command at some stage, but where exactly ?
Also, I didn't take any time (A-B) for this as well, for the same reason as explained.

Peter

[goon-heaven]

Thanks Josef for the super-clean player.
Have not been able to break it, running along browsers/outlook/delphi.
It does not appear too hungry either.
Are you developing it further?
Can we have a version supporting smaller buffer sizes please? i.e. from 32 up?

[Josef]

I'm quite busy with other (DAC) priorities at this moment, and I thought to accept the outcome anyway. Also, with that I don't like the A-B stuff, my outcome will not be reliable (I'd really need 5 days to listen to one situation, and another 5 to the other).

DAC is probably taking a lot of your time - I understand and wish you best of luck!

I don't like A/B stuff myself and also prefer looooong listening periods before making up an opinion - However, this RAM fragmentation thing really hit me immediately: I admit, I didn't expect such a difference at all and was completely taken aback! (a nice way of saying I've decided to post those players to check if I had too much wine ) To my relief, both Marcin & Mani not only confirmed my findings but both expressed strong preference just like I did - tnx guys:)

Anyway, whenever you have time please do try it. And, since you prefer longer sessions (and perhaps there are other people too) the limit of 1 WAV might be an issue: If you'd like to play multiple WAVs then simply copy them to same folder where players are and do this:

- in command prompt (in folder where both players & WAVs are) type: notepad jplay.bat
- Then copy/paste this line:
forfiles /M *.wav /c "cmd /c jplayer2 --file @file"
- Save & Close

From now on you only have to type 'jplay' and all WAVs in folder will be played (substitute jplayer2 with jplayer1 as you see fit).
Don't expect 100% gapless as WAVs are loaded one by one so there's an inherent delay but it should suffice for purpose of the experiment.....

Personally, since I experienced what contiguous RAM can do for PC playback I find myself troubled when listening to any player.....(incl XX)..... Yes, yes, I know, it sounds radical and I don't want to start a controversy here so let's just say it's how it seems to me at the moment, ok? 

And that's why it's really great to hear you will be incorporating these findings into XX! (as mentioned in SFS posts last week it might be a bit of a challenge as RAM will have to be allocated all at once in a e.g. service but I'm sure all XX-fans will aprreciate it once it's there - btw one more reason to get as much participants for this experiment as possible!).