josef

Paul – You brought up a ton of incredulous and very, very serious allegations against us. Allegations which I called to be BS and asked you three times to prove. Instead all you have to say is ‘you guys were just amateur software coders’ and ‘I think you guys are either hucksters or just plain crazy’? For 4th and last time: we just asked you to back up your numerous and incredulous allegations with proof. Frankly, it may help your credibility.

Paul - you say you ‘instrumented Windows’ and found ‘situation is quite serious’ and you also add ‘JPlay can and does destabilize JRMC and/or Windows’. Paul – What in the world compelled you to come out with such, forgive the expression, BS? Surely your sophisticated ‘Windows instrumented platform’ can easily provide tons of examples? Why then do you not provide _any_? Like, you press Play in JRiver and it crashes because of a naughty JPLAY! Or, you press Next and you see a memory leak caused by a very, very naughty JPLAY or, after listening to an album with JPLAY your computer suddenly melted! (as was almost suggested at AudioStream). JPLAY has been available for download for well over 2 years and just for past six months we had over 50,000 downloads - with over 3,500 people creating about 14,000 posts on our public support forum there should be plenty reports of such JPLAY naughtiness, don’t you think so? Miraculously, there just ain’t any…. (and unlike certain company publicly calling us ‘a hoax’ we do not censor nor remove any posts from our forum) But maybe your issues just slipped by and nobody noticed – So we’re enthusiastically looking forward to your test cases!

Paul - what JPLAY does or whether you can see differences on your 'instrumented platform' is not relevant for what you stated. You claim JPLAY causes 'increased application crashes', 'less effective application scheduling', 'less effective memory management' and 'memory leaks'. All very, very serious accusations. I simply asked you do give us an example: That's all.

Paul - Your posts are full of 'adverse affects','disturbances' etc. May I assume you are talking about the old version 4 based on JRMC plugin interface which in certain cases could 'freeze'? If so, you may wish to know JPLAY 5 based on industry standard ASIO proved far more robust and has been available since January. Please try it. If you encounter any issues please let us know so we can improve - Thanks.

Julf – have you just woken up from Rip Van Winkle experience? If after 700+ posts (and quite a few of yours!) you need it explained to you what’s going on(?) then may I respectfully suggest you follow your own advice and find some other place to troll, nothing personal, just some of us here have commitments, day-jobs & stuff, ok? I'll even let you have the 'last word' too...

>If you feel a strong need to continue this one, I suggest you start by addressing the actual questions I have asked you. julf, no offence, but wouldn't it seem you're the one here with an incessant 'need'? (1200 posts in 5 months???) me? i'm just enjoying my hobby which is listening to music via PC and which i (naively?) thought this site is all about? (hmmmm, ‘C O M P U T E R A U D I O P H I L E’ – funny way of spelling ‘physics world’, heh?) thank you for explaining to us that only those whom YOU 'don’t suspect’ and those with verified 'AES-papers' are allowed to post here, I’m sure Chris will incorporate this rule soon and instate you as a resident gestapo enforcer (if not, perhaps an opening will show up at hydrogenaudio - if someone gets run over by a truck, that is)… Oh, btw, with 1200 posts in 5 months I trust you have quite a lot of ‘AES published papers’ yourself? Looking forward to your links so all of us here can learn from your esteemed work…

disappointments galore... ’peer review’??? is that how you evaluate ‘pages of data’ you get from audio manufacturers? for real??? Excuse me, Mr Weiss: can you show me peer-reviewed journals replicating your measurements from Weis 202 DAC data sheet? Mr Meitner, I heard good things about your DAC: can you point me to specific issue of ‘Physics World’ were your DAC measurements were peer-reviewed? rofl... i really expected more from you julf…

julf - fyi: Scully evolved from hard-sell 'scientist' into a far too 'open-minded' person in later X-Files and Mulder is currently immeasurably happy just californicating so I'm not sure your choice of investigators will get you very far but, hey, you seem to know everything better... this is about measurement results i.e. data is up to debate - not what i (or anyone else) understand or not - this is very disappointing coming from you.... anyway, go on if you will, but keep in mind no amount of sophistry can get you out of this self-inflicted disaster: be a man and fess-up, or state your case & fight, or shut up forever...

julf, this whole thread has long time ago been transformed into a 'do all bit-perfect players sound the same?' contest with audiophiles who simply listen saying 'no way!' and 'objectivists' like you who refuse to listen and demand 'measurement data' saying 'yes they do!' similar discussion ensued in early days of transistor amps when a narrow focus led some engineers to measure wrong things and then claim that 'all transistor amps sound the same as long as they measure the same'... or claims that 'better-measuring' transistor amps by definition sound better then 'poor measuring' tube-amps which was even more ridiculous but demonstrates just how arrogant a narrow-minded person can be (engineer or not)... in early days of cd some people claimed that all cd players sound the same i.e. that people can't pick up any difference between cd players 'because they are digital and bit-perfect'... one would think that we have moved forward after so many years to at least keep an open mind but it seems we have to go through the same exercise again and this time with pc-based audio playback...oh well... measurements showing that bit-perfect is only part of the equation and that PC software is not some sort of 'abstract entity in vacuum' but instead _can and does_ actively influence what ultimately comes out of DAC are out there... if you disagree with the method of measurement or have an alternative interpretation of results you are welcome to state your case...

>I think what real engineers/scientists start with is actually making the effort to understand what was measured and how. so why don't you 'make the effort'? you're the one here preaching 'scientific method' to death but when forced to use it yourself suddenly you need help from a 'peddler' or, in best case, 'a well-meaning ignoramus'? (who is also blasphemously happy with just using his own ears as 'measurement instrument' - horror of horrors...) so, peter's english is preventing you from trying to understand? gimme a break... the 'droppings' you'll have to step into once you get of your high horse are of your own making: you just can't blame them on anyone else... how about showing some humility and really 'make the effort to understand' peter's measurements which show in stunning detail that two 'bit-perfect' data streams _can & do_ produce different analog outputs depending on what software is doing during playback... measurements which, btw, nobody ever tried to do because 'it was known' that 'bit-perfect' always 'sounds the same'... measurements which are far, far more complex to set up (kudos to peter!) then overly simplistic DiffMaker... i'm sure you're smart enough to figure out all the graphs even if you have to re-read the text couple times: make that effort, it's worth it... who knows, if you step off that high horse maybe we'll start seeing the capacity of having a meaningful civilized discussion free of 'male cow droppings' after all?....

julf - don't you think it's high time you got off your high horse? you keep banging to death about 'measurements' & 'proof' – most would argue that 'proof is in the pudding' ie for audio in the listening, but ok, if you choose your audio equipment based on how it measures, that's just fine, it's your choice... but have you then missed the link bibo01 posted above? have you missed what peter said? seems you have selective memory so let me remind you: peter was apparently able to _measure_ the difference between otherwise 'bit-perfect' software playback THREE YEARS AGO(!)... there is an interesting graph in that post and even more are linked... now that you're apparently caught with your pants down you react by trying to be funny (very unsuccessfully btw) by bringing up ‘cosmic rays', 'crop circles' and linking to 'clairvoyance' experiments??? are you telling us that is what 'real engineers/scientists standing on shoulders of giants' do when faced with hard data that does not fit their present understanding of a subject?

peter: >When I put up my results in CA, there wasn't much attention to it. could it be nobody reacted because you were just too much ahead of the time? or was it because of your english that people maybe simply didn't understand? (no offence, you're aware of that) btw - seems you forgot to mention cics and his cPlay which maybe was even more ahead...? especially as cics was giving cPlay away for free, documented his thinking in great detail and (apparently?) even gave source code to anyone who asked? i personally did not ask for it (nor looked at it) but let's give the guy a credit for being much more as julf likes to say 'a pioneer' than us... (well, ok, you can keep 'pioneer' title if you like ) so, just like you, i too am amazed about this whole hoopla when it's been at least 5 years since first audiophile pc software playback appeared... (although julf explained to us that it was probably a rehash of at least 40 years of engineering and untold millennia of 'shoulders of giants' but hey, to each his own...) mind you, i do think that what we have today is far better from what was available 5 years ago and that i have brought some new things and upped the level couple notches: and, as you seem to imply, maybe your new version will do the same - that'd be great! i'm looking forward to it as what we're really after is improving the state of the art of pc-based music playback consumer can benefit only if there is a healthy competition - not a monopoly of products nor ideas... btw - there is no problem you banging about XXHighEnd here: this thread has been hijacked beyond repair with Tannoys, Salisbury cathedrals, AT&T, Coca Cola and god knows what: if you don't want to share the link of your 'ancient' CA graphs that's ok - and if you do please go ahead - it actually sounds interesting and FAR more relevant than 90% of posts here...

mark - is Winchester cathedral using jplay?

@julf >But considering software-based audio playback has been around for more than 40 years, I am not so sure. considering cd was invented 30 years ago I find that statement a bit odd… but ok, let’s not quibble over minutiae… >But even at the time, the engineers (both at Philips and Sony) knew extremely well what the limitations of the technology were, understood them, and were quite open about it. you have some links? it would be interesting to read what _they_ saw as limitations 30 years ago especially in light of recent heated debate over hirez… anyway, back to original question: >So why do *you* think the software sounds different from other bit-perfect software? well, mitchco already alluded and it’s not that difficult to guess, is it? if we can agree that it ain’t ‘bits’ (them being of ‘perfect’ health) then which part of 16/44 is left? timing, of course… and one thing we learned since invention of cd is that (as much as you enjoy glorifying engineers) sometimes, just sometimes, engineers don’t know ‘extremely well the limitations of technology’…. that is - unless the link about sony/phillips is going to show that they also understood ‘extremely well’ what is now known as ’the jitter phenomenon’? _that_ is going to be a really interesting read then, can’t wait for the link! but enough: let’s get down to business of seeing if we can use an existing or indeed need to create a new ‘software playback benchmark suite’! just to make it more fun how about we take a typical asynchronous usb dac (as those seem to be the current rage among computer audiophiles and as it also covers no-usb dacs that can be connected via numerous usb->spdif converters) and we start by measuring incoming jitter which, in theory, should also be completely eliminated by asynch interface, right? (and which some dac manufacturers even use for marketing slogans – e.g. Benchmark DAC) since dac manufacturers have probably been doing this for a while does that sound reasonable as a starting point? maybe it turns out that incoming jitter is the same regardless of software player used, or usb cable used or, indeed, regardless whether desktop or a laptop is used? somehow I don’t think so but it is certainly possible… alas, I am just a hobbyist and don’t have access to $$$ jitter-measuring equipment – maybe you have or maybe mitchco has?... no? if neither of us can’t measure then perhaps we should just drop the subject altogether? Nah… let’s do it then as a thought experiment, ok? so, suppose there IS a difference in ‘incoming jitter’ between computers or players – what to do next? well, some people have suggested that, for music playback, usb is inherently flawed delivery format as it’s frequency (1000 packets per second for usb 2 which most dacs use) imparts directly very audio-sensitive 1kHz thereby causing so-callled ‘deterministic jitter’ (worst kind) to appear at worst spot… sounds scary, doesn’t it?…. now, I have no idea whether that is true or not (do you?) but maybe we could then extend our measurement 'benchmark suite' by also measuring exact frequency of usb packets arriving at dac? (1ms is ‘specced’ speed but could it be that in reality it shifts some nano/picoseconds here or there? since clock jitter is now measured in picoseconds and even femtoseconds any variation found could be potentially interesting?…) and while we’re at it, maybe we could also try to vary the size of data-bearing packets (those having audio samples) and measure if that has any impact on ‘packet jitter’? sounds crazy or pointless? maybe, maybe not: what we hear from jplay users is that buffer size has audible impact with smaller buffer near-unanimously being preferred over larger buffer… that's why jplay has DirectLink option which, in a manner of speaking, completely eliminates buffer ie. uses minimal buffer size possible: a single audio sample! (btw, it will not work with every dac/driver/firmware but, to the best of my knowledge, jplay is the only player that can do this most consistently among widest variety of dacs – I mention this not to gloat but to provide you with context background to above claims from users i.e. it seems to be universally applicable to _any_ dac, async/non-async, usb/firewire etc)… and people seem to prefer DirectLink more often than not as apparently differences start to become smaller with larger buffers... of course, this all should not matter at all as pc is limited with fixed usb frequency so it makes no sense to send 1 sample at a time when even cd format needs quite a bit more for 1ms worth of music: but apparently it does (at least subjectively) so maybe it’s not so crazy to measure it after all? but then we should repeat the measurement with different buffer settings for _specific driver_ (if it has some sort of control panel where this can be set - many have, but not all) just to see what is the inter-relationship effect of software player’s buffer and ‘real’ actual device buffer? has anyone done such a measurement? I have not seen it anywhere….. again: do you have the equipment needed? If so, but you don’t have the time I’d be happy to do it! (I see you’re based in nl? great, then you can’t be more than couple hours drive away in worst case…) since this post is (again) becoming far too long let me conclude by addressing one last ‘concern’ of yours: why am I not ‘confirming’ what mitchco picked up as a possible explanation ie ‘latency’… yes, if you look at what jplay does it is pretty much all about reducing software playback latency, indeed! e.g. changing thread priorities, utilizing lower latency ram, reducing task switching, all the way to dumbing-down windows so much that it can’t do almost nothing but transport music bits! ('hibernate mode') - hey, could it be there is a method in this madness after all? so why did I not rush to ‘confirm’ mitchco’s theory when, finally, (after 100+ exhausting posts) somebody ’figured it out'? simply because I like to have at least some kind of proof if I’m to categorically ‘confirm’ something... in other words: i have no reason to suspect playback latency is the reason why bit-perfect players sound different but to confirm that statement I’d have to measure it, wouldn’t I? problem is, this one might be the most difficult to measure of all in fact it might even be downright impossible… why? because we’d have to measure how many cpu clock cycles it takes from the time interrupt ‘need more audio samples’ kicks in and until 'audio samples just dispatched down the wire’ point in time… sure, modern intel/amd cpus can give us timing precision down to a single clock cycle so in theory this should be possible to do: but how to capture these moments without writing a windows kernel driver (a non-trivial task) maybe even one that has to replace ‘standard’ usb driver (a very, very difficult task) and, more importantly, how to inject our time-measuring code into os at ‘right place’ so that we can be 100% certain it is _always_ executing at _precise_ start & end times (so we can trust our time difference measurement as we can't settle for 'average' or 'estimate') when we don’t have access to windows source code? (not to mention the knowledge of how to modify it).. perhaps somebody at microsoft can do it but I’m afraid it’s mission impossible for us mere mortals… but since you seem to prefer linux maybe you can at least do it on linux? (jplay does not run on linux but what jplay does on windows is most likely possible on linux too so the exercise would still be interesting and, at least in theory, this should be easier to do on linux it being open source and all that…) so: do above measurements exist already ‘for 40 years’? if you’d allow me to use your words, ‘I’m not so sure…’ ps. before you just dismiss these proposed measurements out of hand as ‘not relevant’ (actually I don’t think *you* will - rather someone else) may I kindly ask to accompany measurement results which ‘prove’ such assertion? ps2: about your ‘category’: you forgot ‘hobbyist’ but I’d say it’s irrelevant what I ‘feel’... rather, it’s up to you to decide - isn’t it?