Jump to content

PeterSt

  • Content Count

    7488
  • Joined

  • Last visited

6 Followers

About PeterSt

  • Rank
    Senior Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. PeterSt

    CLOCKS, what should we look for in next generation

    Hard to wrap my mind around that. Would we still talk of "reconstructing" with DSD as such (and then regarding the "in every frequency") ? not sure. This would be about that other averaging (like over 22 etc. DSD bits). I think this too was discussed earlier on (in this thread ? but maybe over 6 months ago).
  2. PeterSt

    CLOCKS, what should we look for in next generation

    In the end maybe that too. Also notice how DSD is not a continuous up-up-up or down-down-down (when the "music" depicts that) - see Scarlet Book, and that this in itself adds non-linearity. This could be nit-picking though.
  3. PeterSt

    CLOCKS, what should we look for in next generation

    Maybe nothing. But: You set your own rules. While I did too: and So ... I considered to add to it all "this seems to incur for DSD" (1 bit) but I thought to leave that for Miska to add. OK, he didn't ... I don't remember whether it was in this thread, but there has been the question whether DSD would require a lower jitter system (you using the same or similar math to attest it does not), but now it is about skew. And that seems to tell that this puts DSD in favor of PCM ...
  4. PeterSt

    CLOCKS, what should we look for in next generation

    I like to see chips with skew specifications which are "as is" instead of "40fs min, 60fs max and 45fs typical". Skew itself bears jitter. Only when you use low frequency stuff which doesn't have skew specified, the skew is fixed. In your mind ... Averaged ? Maybe if you average it. But in practice it isn't. Think carefully how this works out from input to output and what might happen to your complete sample before the logical (one-sample e.g. 24 bit) transition is completed. Skew is a given but what we can do is "utilize" (exploit) the facts of it (see Miska's quote which could be regarded that). Skew depends on current usage, which is a (multi)bit not what we want in our AC audio (again Miska's quote). The subject of skew (in the realm of lowest jitter systems) is quite large and the design completely depends on the configuration as a whole which needs to anticipate the physical possibilities (which chips to use) Nothing for a few forum posts.
  5. PeterSt

    CLOCKS, what should we look for in next generation

    Barrows is going to show a better one. But you wouldn't be able to tell ... Anyway let's not be silly. You now know what I meant with the noise level and why. And that one would be better, normally.
  6. PeterSt

    CLOCKS, what should we look for in next generation

    ... Nah ... unless the noise is extreme. And I mean so high that no skirts / lobes etc. can be seen. But I think Miska just showed that, despite ... So hmm. The noise floor must be lower to see anything. That's what I meant.
  7. PeterSt

    CLOCKS, what should we look for in next generation

    Define the output noise level first.
  8. If the electric guitar hadn't been invented, this had not existed. Angus probably hadn't moved to Australia and he also would not have moved house "back" to 30 minutes from where I live. If I see this video, I feel famous.
  9. PeterSt

    CLOCKS, what should we look for in next generation

    PS: With master and slave clocks. I considered that instead of a clock distribution system (see earlier post about the 2500 component DAC). I forgot why I didn't choose that. Probably something with skew. Anyway, this would be a new kind of approach (for a purpose I again forgot but instead of distribution).
  10. PeterSt

    CLOCKS, what should we look for in next generation

    There is "networked clocks" for that (heard of that ? I am serious - and the company who makes them is IMO the best candidate for new ultra low jitter oscillators; I forgot the name by now, but have a quotation somewhere for only a 100 and "doable").
  11. Peter it sounds like you don't believe the stuff that Alex and John Swenson describe ... upstream phase noise fingerprint affecting downstream components and getting past many kinds of isolation techniques? Am I misinterpreting what you're saying? Hey Rick. I guess, like with @incus, many of you guys know a lot more about this than may seem from my responses (and btw, who am I). So no, it is about the difficulty in describing what happens where. Now since referring once again to that larger post from by now two days ago apparently does not help, here a smaller retry in different wording: So that text again (from incus). I'll try it as short as possible: ----- If you would record that, like in a non-volatile buffer, would the added phase noise (error) be recorded ? Of course not, because this is digital. So transfer errors left alone, this would just be a copy like a copy of a Word document. ----- That is actually all there is to say. And oh, whether that copy resides in non-volatile or volatile memory, doesn't make a difference. It is only that the "buffer" we seem to talk about would merely be volatile. The problem with making things clear, emerges here: Once this copy is in-memory (still pushing out towards the DAC and makes sound), you can pull the Ethernet cable to eliminate the Switch, but really nothing - NO-THING - will change to that copy of the data. How could it. It already was 100% fine (after possible error-correction because computers tend to do that ). Done. No wait, ... but it was the stance that pulling that cable/Switch would change sound ? YES. Because in real-time the noise influence (Phase Noise if you want) signature is changing. The digital data stays the same (0's and 1's don't interpret differently). So envision that nice analogue very low level test signal, think 30uV), and when the cable is pulled that noise becomes 25uV. This really isn't hard to imagine, I'd say. This is because this is analogue noise and it may come along with the connection to the Switch and be gone when that connection is pulled. Now, did that change anything to the digital data ? PS: It is not allowed to claim that 5uV is not audible because it is about the principle. The analogue signal has changed and thus that could be audible. And now I didn't even talk about jitter, which actually is ahead of that analogue output signal, and where the noise in the digital signal (which in the end is electrical analogue) influences jitter. Peaks and valleys (1's and 0's) don't trigger at the same time when noise is added (a peak of noise triggers early). So pulling the Switch will lower jitter. And the recorded data (or data in the buffer) will still be 100% equal in both pulled and not-pulled situations. More clear now ?
  12. PeterSt

    CLOCKS, what should we look for in next generation

    Maybe it is not a good idea to compare with specs of a lower base frequency with what audio requires ? (specs will worsten the higher the frequency) Also it may not be a good idea to take synthesis for granted now (it really is not for the better as far as I can tell). And thus it is apples and oranges and (IMO) the Vectron is not the very best. Add to this that you'd thus need audio frequencies and as long as it hasn't been made ... you can be the first and pay the $ for that. Haha. Additionally, never look at oscillators which can be pulled (like this one). That's doing unnecessary no-good to specs (unless you want to make a PLL of course, but who would want that ? ).
  13. In all ways. Just because you are so keen to leave out the proper context. Maybe @Superdadcan't (you were asking him) but I can do that on behalf of him; If you are so good with Process Monitor you might just as well look at a somewhat rougher level and count the task switches. For an optimized system (like with AO) this comes to 46 million switches per second during audio playback (over USB). Allow me to be 50% off for your system. Now ignorant me comes along; In that same system with 46M task switches as by miracle it becomes 680,000. *) Now you are of course going to show me that figure because you can do that too. But that is only step one. Step two would be that you now in *that* context again present your whatever caching and again would say that "these few more" surely won't make any difference. Moral: Everything makes a difference but one has to apply first everything in order to detect its relative effect. Be that a technical matter like a PMI Counter or be that audible effect. Of course, if I'd like to present that an electrical difference of 10mV of noise really won't matter on 500mV of noise (think power supply) then everybody will think that is correct. But if that 10mV is superimposed on 10uV the story becomes a bit different. That, in order to get there, I first had to eliminate a 100 other sources of noise is something else, but crucial context. Someone was talking about that this is not about winning or losing. But you lose. *) IIRC this was for a W8 system and by now 6-7 years ago. Today's W10 will be very different, and varying per Build. Also my own software regarding this evolved quite a bit (focusing W10).
  14. You do understand digital, do you ? Oh, wait ...
  15. PeterSt

    What's the consensus on ethernet cables?

    Just take CAT5. Then you don't have that. And is as good (enough) for normal usage.
×