? 1. You provide a lot of detail on the changes you made to make the system more real-time. None of that matters because existing players are "real-time enough."
So high-end CD transport manufactures targeting picosecond jitter measurements are wasting their time because if you don’t hear any audio glitches timing is already ‘good enough’? Just attach a cable to DAC, it will reclock anyway, done?
No. These are two different topics:
1. Whether the system is predictable or fast enough to play audio samples without interruptions. This is what is meant by "real-time." If the system is real-time enough, the job is done. Making more real-time is of no value. Imagine a robot on factory floor working on assembly line. It may need to start its job in say, 1/10 th of a second. Making it work at 1/10000 of a second will have no value whatsoever. A missile however travelling at > speed of sound needs to be real-time but at much lower latencies. This is a fundamental concept in building real-time systems. You only need to be real-time enough for the application.
In this scenario, redbook CD needs an audio sample once every 1/44100. If we can give the hardware 100 bytes at a time, then we need to service it 1/441 seconds and so on. As long as we are at that level of latency or faster, then we have achieved our goal and being better gets us zero points with the end customer since the system does not work any better.
As I noted, every computer server that people deploy plays audio samples at the required rates as to not cause interruptions. If there were audio drops, we would hear them and they would massively show up in measurements as we would get a glitch that shows up as a ton of distortion. So the system is real-time enough. And fundamental principal of real-time systems says there is no more merit than being better.
2. Fidelity differences with respect to DAC clock accuracy. This has nothing to do with the above concept. I can vary the clock jitter by many nanoseconds with the system still playing reliably with no glitch. Distortion however would be generated due to jitter and this is what high-end companies aim to minimize. A $10 CD player and a $10,000 one however, are both real-time enough to play the same content. Neither glitches when playing audio.
Yes, there is a point at which clock jitter can cause lock to be lost and we get a glitch. That is not a concern here. Again, no one has experienced jitter lock being lost with their DAC and fixed it with Jplay.
I did not set a target for clock jitter when I said "real-time enough" as you imply. Real-time enough strictly applies to proper functionality per #1 above, not fidelity. Your responses and claims for the software constantly mix these two topics together.
Please read again section on buffers: ‘existing players’ all use relatively large buffers to ‘cheat away’ fundamental issue of having to provide a real-time service (audio streaming) in a decidedly non-realtime environment which offers few promises and no guarantees about timing whatsoever.
As I said, it is off-topic. I can play music 100% reliably with all of these media players. They are all for the purposes that we have, are "real-time." You have made the system no more reliable by the changes you have made since the end experience is the same: JRiver plays without interruption, you play without interruption.
Yes, at the core, the system is still not real-time. I can for example put the disk drive in sleep and if you try to play, it will take a few seconds for it to wake up to play. You could also have too little memory and start up photoshop and have it cause paging and playback glitching. If these were real problems for users and you made them better, then you would have a case there. But these are not problems people face or care or think about fixing with your software. Your marketing message is a fidelity improvement, i.e. #2 above. So the constant talk about #1 is a distraction.
Nothing wrong with that except experimental evidence suggests _smaller_ buffers seem to increase sound differences (yes, most say ‘it sounds better’ and no, I don’t have a nice graph for you – shoot me) but are much harder to work with as danger of glitches increases exponentially. So I’m afraid ‘it matters’.
Have you taken any blind tests and seen how accurate your assessments are? If not, you should. I was once helping my codec team optimize our encoder. They gave me a dozen parameters I could tweak. I tweaked them over many painful days to many decimal places. The team was shocked as they told me none of the fractions were used. I told them they were crazy as I could easily hear the difference. They give me two sets of files and ask if I can tell the difference. I listen and I say sure, they sound different. They tell me they were identical! And this is coming from someone who was trained as an expert listener and could hear artifacts few people could. So while I am not dismissive of subjective assessments people make, they don't have value when they try to convince *me* of some technical fact.
The bloggers that have tested your software took the analog output of the DAC and analyzed it. All that happened up stream including the buffer changes, real-time this and that, was ultimately boiled down to that waveform. Those waveforms did not differ with or without your software down to the accuracy of testing. So I am afraid you do need to have your own graph to counter them. Everything else is hand waving.
As I noted to John, you are making specific technical claims, connecting certain dots. That theory can be easily tested as the bloggers did. And their results, says that your theory is not valid in their tests. Of course they did not test all scenarios. So maybe it matters elsewhere. Problem we have is that you, as the proponent of these changes, have no data either. I even gave you the low hanging fruit: take the PC motherboard sound and see if your changes make a difference there. I think there is some chance that it might there. But you are not going there. And certainly have not in the past.
As with my experience above, you may very well have heard the wrong thing as have other's testimony you are using here. You need some way of ruling that out. For your own sake if not ours.
>But in the manner our members use the system, usually as a dedicated machine, the system is real-time as a CD player is in that audio is not interrupted.
No offense but you cannot twist definition of real-time as you see fit: it either is or isn’t realtime.
Well, it is an offense because the first company I worked at was in the business of selling real-time systems for such applications as flight simulation. I was hired on to work on Unix and to see if we could make it real-time enough vs their proprietary system. We did not get there but in lighter applications we did manage to make Unix "real-time enough." I worked there for many years in 1980s so please don't tell me what a real-time system is or isn't. Or what its definition is. I know what it is as it was my job to know.
Your comment above indicates that you are not familiar with how real-time systems are quantified. I hate sending you to the Wiki but let me do that and save some typing:
http://en.wikipedia.org/wiki/Real-time_system
CD player, by definition, is realtime and Windows is not.
Windows is not. But if I play a track on my music server, it is every bit as real-time as CD player. It plays the track without interruptions. And again, no one is buying your player to fix a problem there.
These are facts which do not depend on ‘manner of usage’ and have nothing to do with whether audio is interrupted or not.
If you play a scratched CD and audio gets interrupted does that suddenly turn CD player into a non-realtime system?
If the retry mechanism in the CD player takes too long, yes. The system needs to have enough buffering to keep playing while that retries. If the media cannot be read at all, that is a system failure and has nothing to do with the topic at hand.
>No one I know that buys your software has expressed that they bought it because Jriver glitched and yours didn't.
Good – otherwise it would mean JRiver is utterly broken ?
Seriously: who ever suggested anything of the sort? The whole point is not about glitches but whether ‘good enough’ is enough or can be improved by optimizing the environment.
90% of your marketing material and explanations go toward this point. You have people like JKeny who then believe it to mean fidelity is improved which is an orthogonal topic as I noted in the start of this answer.
>You say you are software guy. That is a problem… I live and breath the full spectrum and it is in that context that I find issues with your approach.
I freely admit not being particularly smart and not having multiple hats like you do and I am happy for you. I have no intention to debate with your other hats as those are beyond my limited competence but you did talk about software in your post and this guy with no hat at all felt you were incorrect on several important points, whichever hat you were wearing – that’s all.
If you think my descriptions were in error please do correct me like I corrected you on specific points.
I don't want to lose the audience over detail that is off-topic. I might comment on them later but for now, we have to get one thing clear: you can't confuse changes that make the system more real-time with higher fidelity. You either agree with this or we stay on it 'till we resolve it.
>You should measure and document….You need to add other skills and disciplines to your assets to understand why I predicted that measurable improvements would not be there and that is what has come to pass.
Amir – I’m a flawed human being with limited skillset but that’s just how it is: take or leave it. It’s a bit too late for me to go back to school and get multiple PhDs so if that is required to be able to enjoy the music or participate in this forum then I’ll respectfully move on.
Cheers,
Josef
Those skills are required if you want to convince *me*. It is not a requirement to enjoy music or stay in the forum. And you don't need to go back to school either. Just need to read and accept a bit what I am saying
.
