Jump to content
IGNORED

XXHighEnd


BEEMB

Recommended Posts

... some have reported crashing, with Mail.

 

No issues here in that regard, but check it out before

relying on it. Of course you can alway 'un-install' and

revert to previous version if you have issues.

 

Lots of other percs too with version 4.

( In some cases I find it so fast I can't notice

that a page has reloaded! )

 

Link to comment

I guess I know why I don't hear many of the differences. As one poster puts it:

 

"Man I am totally dying to find out how one could tell which files were which; I got 5/14. Very tiring and frustrating..."

 

Many of these guys I think are sound engineers. Read up on what they are looking for to tell the difference between files.

 

www.hifiduino.wordpress.com

Link to comment

mpmct, I'd be happy to try ABX this weekend if I get a chance. My priority this weekend is to get XXHighEnd up and running, which is the focus of this thread.

 

Is there a version of ABX that runs on Windows computers or does it only run on Macs? Can I choose the media player software or does ABX use its own? Are there audio files limits in terms of file formats and resolutions?

 

Please feel free to start a new thread by just replying "Please see my new post".

 

Thanks,

Z

 

Link to comment

Matt, I know you have it in your mind quite well, but the words used to express it are confusing I think;

 

That other software running influences, true. But this is not because it takes away the capacity needed for the player. But if that were so, you'd not be talking bit perfect anymore, right ?

 

So yes Tim, if you feel that wasn't "it" (Matt's expressions on this), you are right.

 

First, think in terms of jitter. Forget for now about the DAC rejecting it (already because that is not so for 100%, unless the DAC is operating completely asynchrounously). Thus, jitter. I said this about it in an earlier post :

 

In fact, all is about the sufficient control (think PSU like) to not let emerge jitter. Keep in mind that jitter is a (non linear)shift in the time domain, where all is about snapshots taken at a predefined (the clock) interval, the data streaming under those snapshots, and the 0 and 1 (just electrical) signals are caught on their slopes of sufficient electrical level to be caught as a 1, or just not with the result of a 1 being captured as a zero.

 

It is not difficult to see that the worse the signal (for various reasons including noise or reflection because of wrong termination (the termination residing at the transmitter side !), the electrical level of a 1 is too low, or the noise is too high and before a 0 is a 0 it will be captured as a 1 (note the activity in my "before a", which is related to the stream and the "snapshotter" looking at it).

 

So, inject noise (Chris's post) and the electrical (just analogue for that matter) 1's and 0's become more vague, and jitter (reading 1's for 0's and the other way around) is the result of it.

 

Before proceeding, a little twist maybe, accidentally addressing Roseval's remark;

It is not for nothing that my 24/192 NOS DAC has an I/V (current to voltage) stage consisting of a Super Shunt regulator ("Super" is not about excessive, but just an existing phenomenon for shunts). This is about the current draw from the one element not taking away necessary current from the other. Mind you, we are talking about near nano volts here, and if (for example !) the left channel requires 1.5V output while the right channel needs 5 uV only, without attention the current needed for the 1.5V will make the 5uV vanish completely. Or make it completely unreliable the least.

A Super Shunt consists of "mechanical" mechanisms that counteract this automatically, and the 5uV will be output accurately always.

 

With this as the example, I think we're all pretty well able to imagine a PC with a dozen of chips and things, and they're all requiring their mWatts, and they require it at virtually random moments (thousands of times per second), and the negative implications of it.

There is no such thing as a regulated PSU apart from "try to keep it a 3V boy !" which is infinitly worse than what is needed for a steady stream of "data" regarding the audio we talk about. This means :

 

All software processes performed in the PC, no matter how tiny, have their influence on the available current, and while there's sufficiently available, it will fluctuate because of it;

 

Next in play, is the TTL standard, thinking of this being all about a digital stream, and the 1 being recognized as such because the standard says so. For example (I didn't look it up), TTL might say "when a signal of 2.3V is detected, it is a 1." and "when a signal below 0.8V is detected, it is a 0".

The point now is, that at going from virtual 0 to virtual 1, the rise time plays a role, and the faster this happens (current !) the more precise things are. Fall time (could be feed back) ditto.

Back to jitter and the PSU influence ... the rise and fall times will vary because of the current not being constant.

 

Now think of the snapshotter again, and you may be able to see how jitter emerges from software influence.

 

About XXHighEnd and jitter ... I found ways to deal with this. Some are explicit from the beginning, some emerged by learning from (negative) results and with the help of others, some more will come.

And some I'll possibly never understand while I *am* able to control it.

 

Voodoo ...

Peter

 

Lush^3-e      Lush^2      Blaxius^2.5      Ethernet^3     HDMI^2     XLR^2

XXHighEnd (developer)

Phasure NOS1 24/768 Async USB DAC (manufacturer)

Phasure Mach III Audio PC with Linear PSU (manufacturer)

Orelino & Orelo MKII Speakers (designer/supplier)

Link to comment

Thanks Peter. I'm no engineer and I won't pretend to have understood all of that, but I think I got the gist of it -- imprecision in the digital data as a result of varying demands on the PS, etc...digital data being nothing but on/off, the only imprecisions could be errors -- a zero being read as a one, which would be obvious, and timing errors, which would be jitter.

 

So we're back to jitter again, which makes sense as it is really about the only thing that COULD be different in two identical, bit-perfect streams. I thought jitter only occurred at conversion, but again, I'm no engineer. No matter. This we can measure. If there is a difference in sound, there has to be a difference in jitter levels, post-DAC, from the same file, same DAC and cable. Of course those differences, if they exist, may be very small and we could, again, enter into the old audibility of jitter argument. That's were ABX testing comes in. If jitter measures the same, we're done. If not, then we need to determine if it is audible. Of course I imagine the first step is complete. Surely you've measured the jitter levels. My apologies if you've already published them and I missed it. Just point me to that thread.

 

Tim

 

I confess. I\'m an audiophool.

Link to comment

Sadly, although I have the equipment to measure since the beginning of January, I could spend a couple of hours on it only.

 

It is not an easy job anyway, because normal measurement generates its own data to measure against, while in this case this is useless. So, there must be static data (a "music file" comprising of certain wave forms) loaded into the player, know what to expect from it, and hold that against the measurement means. This will not be something the measurement device (+ software) can do by itself, and it needs interpretation I am not familiar with yet. So it takes time to learn.

 

Might you want to know, I bought the $$$$$ device just because of the reason "what we hear must be able to show by measurement as well".

Call me crazy. But hopefully it shows that I am very seriously working on this, and possibly from theories might follow some science.

 

Peter

 

PS:

the only imprecisions could be errors -- a zero being read as a one, which would be obvious, and timing errors, which would be jitter.

 

Point is, jitter is about reading errorneously. "Reading" is the wrong word though, and "interpreting somewhere along the lines" would be a better one. I had that in my before post at first but scratched it to avoid confusion. So : timing errors (jitter) is about wrong interpretation and in the end just errors.

And before someone comes up with it : the story about the 1's and 0's is simplified, because it is about complete samples being missed or repeated. a 16/44.1 sample comprises of "words", one word per channel per sample, a word comprising of 2 bytes, a byte being 8 bits (the 0's and 1's). So the jitter stuff playes a role on a more "functional" level ... that of the samples.

 

Take one character as a sample, and this might be the result

Takk oneecharrcterrasa ssampll, ann thhs miggt bb theeresslt

 

I think the above is a good representation of the effect of jitter. Also the functional effect seems quite clear. You can still read it, but obviously not as easy, and you'll take the errors for granted. However, try this for 10 minutes and you'll be quite tired (fatigue).

 

Lush^3-e      Lush^2      Blaxius^2.5      Ethernet^3     HDMI^2     XLR^2

XXHighEnd (developer)

Phasure NOS1 24/768 Async USB DAC (manufacturer)

Phasure Mach III Audio PC with Linear PSU (manufacturer)

Orelino & Orelo MKII Speakers (designer/supplier)

Link to comment

 

Take one character as a sample, and this might be the result

Takk oneecharrcterrasa ssampll, ann thhs miggt bb theeresslt

I think the above is a good representation of the effect of jitter.

 

I don't think so. Indeed when jitter becomes very high, bit flipping will occur but this is rare and if it happens in case of audio, clearly audible. You will hear a pop, a crackle. This is rare

Normally jitter is about very small deviations in the sample rate at DA time.

As there is no perfect clock, jitter is unavoidable

The trick is to keep it below audible level

Listening to digital audio is listening to bit perfect jitter!

 

 

Link to comment

So it is jitter then. I didn't know jitter could be generated by playback software. Your example is news to me as well. I'd have thought that kind of error would have been as obvious in music as it is in the sentence you wrote, that jitter, to use the same analogy, is more like minor, random variations in the spacing between words. Bad kerning, to carry the analogy much too far.

 

Is there something different about this kind of jitter that prevents it from being minimized to below audible levels by a good DAC after it is created in the software? In any case, I look forward to the results of your measurement.

 

Tim

 

I confess. I\'m an audiophool.

Link to comment

Roseval, I'm not sure where we don't communicate, but I said exactly the same in my last post (indicating that the "bit flipping" (denoted as 1's and 0's) is too simplified. That's why I used the sentences and appointed one character to be one audio sample. Nothing flips here, but shifts (at the sample level). So, a sample can be missed, and a next is likely to be repeated.

 

This is not wrong, is it ?

 

Lush^3-e      Lush^2      Blaxius^2.5      Ethernet^3     HDMI^2     XLR^2

XXHighEnd (developer)

Phasure NOS1 24/768 Async USB DAC (manufacturer)

Phasure Mach III Audio PC with Linear PSU (manufacturer)

Orelino & Orelo MKII Speakers (designer/supplier)

Link to comment

I don't think jitter is about a sample missing or repeated, each sample is converted as it is, only the cycle time between the samples varies.

 

Take one

Takk one

Takk is an obvious error (bit flipping)

 

Ta ke on e

is more like jitter or as Tim aptly phrased it, bad kerning

 

 

Link to comment

 

Peter,

 

I think I'm there ... so, the demands of software on your computer hardware, which places load on the power supply, can cause jitter.

 

So, it's not other tasks interrupting processes, it's the load on the power supply.

 

Chris - yeah ! - my reason for involving an enginner is probably more related to another discussion regarding media players and why they sound different. I'm just after his opinion and, if he was one of the programmers, he should have a good idea of how the engine works. I'm just really interested. We could start a Mac v PC debate .. ;-)

 

Matt.

 

HTPC: AMD Athlon 4850e, 4GB, Vista, BD/HD-DVD into -> ADM9.1

Link to comment

Chris,

 

I asked further up the thread; I remember a big build up to your XP server in which you made a comment regarding it's audio quality being nothing short of stunning.

 

I'm assuming you've gone back to using Mac OS more so than XP?

 

I do like the idea of multiple operating systems on one machine. Your boot up OS selection screen is pretty cool.

 

Matt.

 

HTPC: AMD Athlon 4850e, 4GB, Vista, BD/HD-DVD into -> ADM9.1

Link to comment

"I think I'm there ... so, the demands of software on your computer hardware, which places load on the power supply, can cause jitter."

 

I can't imagine that it is quite that simple. If it were, the answer would be to simply replace the PS in your computer with something over-engineered for the task. And in the case of a laptop, that would be as simple as plugging in an outboard PS. No skills required. Surely someone would be marketing such a solution? Besides, with jittery iTunes being by far the dominant digital player, wouldn't this jitter be addressed, along with all other jitter, regardless of its source, by the prodigious efforts of DAC manufacturers over the last two decades to drive jitter below audibility?

 

There must be something more here.

 

Tim

 

I confess. I\'m an audiophool.

Link to comment

There must be something more here.

 

But this is why I referred to the super shunt regulator. This sure is nothing very common, and to give an idea : the DAC board in my DAC is some 6 x 10 cm (2.4 x 4 ") while the regulator and I/V stage going with it takes 43 x 27 cm (17.2 x 10.8 ") and has a couple of 1000 parts. This is all rather sophisticated, and I don't think it can be bought as "a PSU".

 

But of course just a better PSU should help, and many people apply that !

 

Lush^3-e      Lush^2      Blaxius^2.5      Ethernet^3     HDMI^2     XLR^2

XXHighEnd (developer)

Phasure NOS1 24/768 Async USB DAC (manufacturer)

Phasure Mach III Audio PC with Linear PSU (manufacturer)

Orelino & Orelo MKII Speakers (designer/supplier)

Link to comment

The fact is that all this is measurable and provable so measure it and prove it or drop it.

 

Dear Ashley,

 

You are right about the first halve of that sentence.

Now, this time it took just over 90 posts before something like the second halve turned up.

 

Can you PLEASE set yourself to drop *that*.

Thanks !

Peter

 

Lush^3-e      Lush^2      Blaxius^2.5      Ethernet^3     HDMI^2     XLR^2

XXHighEnd (developer)

Phasure NOS1 24/768 Async USB DAC (manufacturer)

Phasure Mach III Audio PC with Linear PSU (manufacturer)

Orelino & Orelo MKII Speakers (designer/supplier)

Link to comment

Roseval, if that were true according to you last example, the time would be stretched. Of course with another font :-) it could shrink just the same, so you'd be having variations in frequency. Allright ... (I mean : recognizeable).

 

But if this were so, or - of it were that simple, the only thing we'd need is a super steady clock at the end of the chain, and that problem (of your example) would be out of the way.

But I think you will see that when this is worked out, you'd be missing the samples here and there, or repeat them (the both go along).

 

This last problem is not to be solved with a not-steady clock, or more realistically, with a clock following the variations of the input, because then you'd have exactly what you described. Hence nothing is solved.

 

I'll gladly admit that I may not know exactly about which point in the DAC chain I am talking, and I merely think in "net results". I may even be talking about aspects others never do. It may be unjustified that I do, or unjustified that others don't. I really don't know at this moment. But what/how I think is this :

 

Suppose the incoming stream runs fast. The clock of it cannot be controlled by the DAC.

The DAC has the super steady clock, and it reclocks (SRC in between). It doesn't run fast and it doesn't run slow.

This will lead to loosing samples.

 

Same situation, but the incoming stream is jittery like from your example.

This will lead to loosing samples, and duplicated samples.

 

Note that I never heard of DACs and buffer under- or overruns. It can't exist (because it would create a huge problem).

 

Only when a large buffer is in between, counteracting jitter for an hour of music (such a buffer must be some 4-6 minutes long), there is no problem.

These DACs exist (at least I think they do by now), and this is not for nothing.

 

When no reclocking is applied, I think you will be correct and your example applies.

 

When reclocking is applied, and the buffer I talked about is sufficiently there, your example again applies, though with very little jitter in this case (assuming decent reclocking and a low jitter clock).

 

So ... what I talk about (and again, justified or not) is about the reclocking without a large buffer to sustain the jitter for an hour or so, and thus we must be dealing with skipped and repeated samples from my "sentences" example.

I feel this is legit more or less, because the "super" jitter rejection of SRC principles and all don't seem to work. This is about the IMO very important question from Tim :

 

Is there something different about this kind of jitter that prevents it from being minimized to below audible levels by a good DAC after it is created in the software?

 

Please keep in mind we have this rather strange situation that we're not listening to a static DAC with "some" jitter figures which we just *have* to take for granted (how does jitter sound, until what amount can we perceive it, and what I perceive, what actually is that ? -> Roseval, you good remarks about the analogue stage !) ... but instead we're listening to a DAC, no matter the jitter figures, and the sound of it can be influenced by XXHighEnd.

 

The DAC I use currently has jitter specs of between 0.5ps and 3 ps (not wobbling, but depending on the input used etc.), and while I was very happily creating this DAC, I was kind of sad throughout the process I would loose my own XX influences. But now the DAC is (near) ready, it appears that I didn't loose those influences at all !

 

Nobody is going to tell me that I can hear jitter variations (remember, we would be talking about jitter spec A (XX setting A) vs. jitter spec B (XX setting B) and that *or* XX makes 200ns of the 3ps spec, or makes 0.03ps from an original 3ps). So, besides that I think this is impossible to create these variations, I will not be able to hear it.

And thus something else must be the matter.

 

So ... if the incoming jitter behaves via-via as I suggest, and thus leads to repeated and skipped samples, the audible result will be very similar to jitter (I began to explain this, but got stuck in my own words, so scratched it).

 

When I'd force myself to think about what actually would happen in a (small) buffer with ready waiting samples, I can only come to the conclusion that I don't know. I would had to make up things. Things like the software (SRC) looking at the clock data (think I2S) and missing the pulse and the sample being discarded because of that. Or capturing the pulse twice and reusing the same sample.

 

But please keep in mind, no matter how off my reasoning may be, something must be going on beyond of what we assume as normal or working. It is too easy to influence sound on a DAC with very low jitter specs ...

 

 

 

Lush^3-e      Lush^2      Blaxius^2.5      Ethernet^3     HDMI^2     XLR^2

XXHighEnd (developer)

Phasure NOS1 24/768 Async USB DAC (manufacturer)

Phasure Mach III Audio PC with Linear PSU (manufacturer)

Orelino & Orelo MKII Speakers (designer/supplier)

Link to comment

Ashley James wrote:

The fact is that all this is measurable and provable so measure it and prove it or drop it. Proof is needed or this is simply meaningless conjecture. It really is that simple.

 

Over at Hydrogenaudio, where they have the following condition within their TOS...

 

Hydrogenaudio is supposed to be an objectively minded community that relies on double-blind testing and relevant methods of comparison in discussion about sound quality. The usual "audiophile" speak of non-audio related terms which are completely subjective and open to redefinition on a whim, are useless for any sort of progression in discussion.

 

...have also got a thread running regards the XXHighEnd player;

 

http://www.hydrogenaudio.org/forums/index.php?showtopic=68514

 

Anyway, thought that might highlight what Ash is saying. I have to say I agree with him actually. If I was to spend over 60 GBP (although I'm not sure this is correct as I haven't received a response to my question regards pricing, so please ignore if I'm wrong here) on a media player, I'd like to at least be able to consult some objective tests and comments before doing so.

 

I think this forum could benefit from a similar principle as that held over at HA. Very useful for the noob, looking for some facts and figures.

 

--

djp

 

Intel iMac + Beresford TC-7510 + Little Dot MK III + beyerdynamics DT 231 = Computer audiophile quality on the cheap! --- Samsung Q1 + M-Audio Transit + Sennheiser PX 100 = Computer audiophile quality on the go!

Link to comment

I agree fully, though Hydrogen's are not my way.

 

I only nagged about the message "or drop it" which is completely unnecessary when a few posts back clearly was stated that measuring is on-going.

 

To put it in some different context : while you want to know what to spend 60GPB on (although I'd say listening shoud suffice for either decision), I bought $$$$$ equipment in order to know what I sell.

 

Besides that, and possibly more important, it could be so that we *all* want to know what is going on here, and coincidentally that includes me.

 

A bit of reasoning is justified, and it could even lead to better measuring.

Well, that's my thoughts.

 

 

Lush^3-e      Lush^2      Blaxius^2.5      Ethernet^3     HDMI^2     XLR^2

XXHighEnd (developer)

Phasure NOS1 24/768 Async USB DAC (manufacturer)

Phasure Mach III Audio PC with Linear PSU (manufacturer)

Orelino & Orelo MKII Speakers (designer/supplier)

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...