Hi Gerard - Can you double-click 'Lock Pages in memory' (uh, what was that in Dutch again? ) and send THAT screenshot? (you should be listed there)


Also - do you have enough RAM i.e. did you maybe make a HUUGE Ramdisk? If so, try making it smaller!

I was rather ill past couple days and had to stay in bed...
As I had nothing better to do I played with jplay and to my complete surprise found couple more things that apparently no other PC player is doing at the moment so I decided to try them out and see if they made a difference...

Attached is small Sunday gift to everyone: 'New & improved' jplay but this time in _both_]32 & 64-bit native versions.
Oh, yeah - some people claim that native 64 sounds better! (Ah - It was about time for another controversy!  )

But hey, talk is cheap, so if you have Win7 64 or Vista 64 (=recommended) now you can try both versions yourself - Just like with previous experiment they are completely identical! (in terms of source code, of course).

Those with 32-bit OS won't be able to run 64-bit version and test this - sorry. Nevertheless, please do give 32-bit version a try - you just might find it worth your while...

Just unzip proper package for your OS, copy your WAVs in same folder and type 'play' from command prompt OR, simply double-click play.bat

Again, please share your thoughts & have fun!

Yes Mani, my typo - you are 100% correct!

BTW - You mentioned that your RAMDisk is not allowing you access from command prompt - that is weird!
What RAMDisk is it?
Do you see its drive letter in Windows Explorer?

Ok - I'll mail you download link.

Goon-heaven: Thanks for kind words!
But oh, don't worry - it will break (only player2, that is).
Eventually, Windows will be unable to allocate enough large blocks since this little player always starts 'from scratch'...


I definitely did not plan to.
But, as I explained in my previous post, for some weird reason I'm now having trouble listening to other players so I may add a tweak or two before XX & other players incorporate this finding  

I think I understand rather well what would have to be done to make it go _all the way_ but it would involve some serious dedicated time and at this point in time it's just a hobby for me so no guarantees....


Ah, the proverbial latency mystery

Well, long story short, I'm afraid it's technically impossible (it seems that WASAPI-induced overhead is putting a hard limit on how low you can go.... btw, I'm really not an expert on this so maybe somebody can chime in?...)

Notice e.g. that XX does not even offer buffer size selection in WASAPI mode - there must be a reason for it
jplayer can go down to 256 samples on my run-of-the-mill laptop with vLited Vista without problems (not that I find it sounding better though!).
In fact, the original MS sample code I used was programmed to use lowest latency possible by default (as reported by WASAPI layer) and, in my case, it turned out to be, think 132 samples. Unfortunately, that sounded really bad: as in: totally distorted sound, pops & clicks + the feeling as you were playing an SP tape on LP speed (if you're old enough to remember analog tapes lingo ).

Of course, there's always a possibility of replacing WASAPI with KS and, actually, it may not be too difficult to do it....
Hmmmmm: WASAPI vs KS: Sounds like an idea for a 2nd experiment...?   

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!).

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!

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

?
It doesn't matter, does it?

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

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


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? 

I'd theorize this could simply be another manifestation of a more fundamental issue we also discussed in SFS thread last week: namely, it could all be related to RAM fragmentation.

But, hey, talk is cheap - wouldn't it be great if we could somehow test this and let everyone make up their own mind?

To that end, I am attaching 2 small test programs for anyone curious enough to try!

BTW Programs are based on publicly available sample code provided by Microsoft which means there's nothing fancy there: just super-minimal console WASAPI demo. Although, I did have to modify the code a bit to make it 'Audiophile Approved' (LOL). In other words, all disk I/Os during playback have been removed: it's now a true mini version of a 'memory-based' player )

But the point is this: both versions are _absolutely identical_ except in the way they allocate RAM: One uses 'traditional' approach (well, maybe a bit more advanced than you'd see in Foobar, iTunes etc but no major differences) and the other uses Large Pages (which, to my knowledge, is not used by anyone, incl. XX so it's at least 'certifiably different' ).
So now you can judge for yourself (and with _your_ hardware/audio setup) if this RAM talk makes any sense at all!

Before you start playing though, we'll need to do some preparation work: by default, Large Page support is disabled by Windows as it is not something for 'typical' users/usage scenarios (and also removes precious resources from under Windows' control) so you'll have to enable it manually like this: (make sure you have Administrator privileges)

1. open Control Panel->System->Administrative Tools->Local Security Policy
2. in left panel, open "Local Policies" and click on "User Rights Assignment"
3. in right panel, double-click "Lock pages in memory": If your username is listed you're set!
4. if not (more likely), click on 'Add User or Group' and in popup click Advanced and then click Find Now: this will show all 'users' (most are 'system users'): double-click on one you are using to log-on i.e. one you will use to run test programs
5. close all dialogs with OK & make sure you appear in the list in step 3.
6. reboot (so Windows can activate our new policy)

Oh, since sample code is based on WASAPI you may also wish to play with MMCSS registry settings:
http://msdn.microsoft.com/en-us/library/ms684247(VS.85).aspx
But, if you're lazy, just download & double-click ProAudioKey.reg attachment


To run test programs:
- copy your favorite song(s) into the same folder as attached executables
- make sure you use plain 16/44.1 WAV format!
- also, please make sure your sound card is set as 'default' in Windows and format is set to CD 16/44 (if your 'normal' setting is 24/96 or whatever)

Start Command Prompt (told you it's stripped to the bone - there's no GUI or anything here...) and in the folder where you have put everything simply type:

jplay1 --file YourTestTrackName.wav

Listen.
Then, in same way, try second version:

jplay2 --file YourTestTrackName.wav


Then try with some more tracks. Also try the other way 'round or try several WAVs with one and then other version.
Then try opening your browser, Outlook, anything that eats memory - chances are, jplay2 will report that it cannot allocate memory. Then try again jplay1 - it should still work but listen how it sounds. Then reboot and try again.

Finally: share with everyone if there is any difference between two programs!
Have fun!

PS. If your sound card does not like default buffer size (1024 samples) you can change it: just type program name without any parameters for instructions....

While you do have a point there, as Peter said, we don't really know at the moment what was the actual turn-off reason. Hopefully, Bill will elaborate on specific issues.

But, now that you ask, (Peter, it's manis fault ) regardless of specific problem, I think an easy case can be made at least for default 'sizes': first, XX window is small hence everything feels pushed into an artificial straight-jacket (why is it small? to save space for something else? what? and making XX full-screen will leave everything as unreadable on 1024x768 as it is on 1920x1280 (even worse)?), font is too small hence hard to read (again, why? do most people really demand to see every song title in playlist on-screen even if they need magnifying glass otherwise they refuse to hit 'play'?) and what about those super-tiny buttons all over the place that even I (admittedly, a tiny bit under 75) have trouble hitting much less figuring out what they mean (icon for Quality Panel means.....what? And button to the right with 'X' means CoverArt Cache, obviously, right?) so I'm forced to hover the mouse over and read explanation in an even smaller font size? (and don't even get me started on opening/collapsing panels again seemingly saving space for ... what exactly?.....)

Heck - don't get me wrong, I really don't mean to be negative (rather: constructive criticism).
Of course JRiver a.k.a iTunes-like interface also has deficiencies & can be improved as well!
But wouldn't it make sense to do it the way most people are used to instead of re-inventing the wheel?
So most people can just 'use it' and enjoy the music which was the point anyway - wasn't it?

>Tried 8 different Linux distro's and settled on Ubuntu 10.04 as I was able to upgrade it to the latest alsa drivers. Once this was accomplished, I have been very satisfied with the sound coming from my Benchmark HDR coupled to my McIntosh MC-275 amp. Sound quality is simply the best I have heard.

Wait: 75 years young, playing music via computer (after testing EIGHT! _Linux_ distros!) and listening on McIntosh 275???  

Bill - Don't tell me you actually got your McIntosh in 60's when they originally came out? That would be too much

We need to put this into perspective guys: McIntosh 275 is still made today based on original design from, what,  1961?!!! (gosh, I personally converted from transistors to tubes after hearing that same amp....)
I mean, can you imagine Apple selling Apple II in 2027 and some kid even looking at it?????

Wow, I wonder when I'm 75 if I'd still be up to try, hmmmm, Windows 17 or 8 Linux 203x distro's
 
Bill - Respect!
Post of the month!

PS Peter - May I suggest something gets done about that GUI (a default 'simple' mode perhaps?) if for no other reason than to get Bill to still another level: I mean, where on Earth can you find audiophiles like this? No such forum anywhere.....

Then maybe you can share how you measure 1ms latency i.e. what settings you are using with your WASAPI player and what settings you tried with XX so maybe somebody can help with latter?