Lee Scratchy's Interface Jitter Google-Fu Skillz

Hi guys, long time lurker here.

https://kitsunehifi.com/product/intona-usb/#reviews

"its ability to suppress the known 8Khz USB Packet noise issue far better than most devices"

Sounds totally made up or? They also forgot to mention that DC-to-DC isolators add hundreds of mV ripple, so much for audiophile use.

 

The Regen Amber+9V iPower unbearably shrink and color the SS of Modi Multibit IME, best option I've found is a 10cm dual-shielded USB cable to a highly pimped USB controller using OS-con caps & 1ppm clock

And I'll never understand why anyone would care for S/PDIF & AES when both are actually completely broken by design: https://www.gearslutz.com/board/1788545-post2.html

It all sounds different because everything is out of specs.

 

So, basically, you're saying to use a clock that's three orders of magnitude out of spec, with a cable that'll likely be out of spec (characteristic impedance), with whatever a "highly pimped USB controller" is (how do you "pimp" an ASIC?)?

And this in a situation where, for USB 2.0 Async connections, the USB clocks is irrelevant to sample/DAC jitter anyway?

Apparently an opinion not supported by ever having implemented any of the three interfaces in question.

 

lol yeah, sorry to disrupt the big boys, I'll keep reading and shut it from now coz this thread is serious fun with some outrageously OCD'ed ppl daisychaining USB gizmos and expecting miracles and others resorting to a consumer protocol from the 80's that happily mixes both signal and clock into the same crapola signal, who needs I²S & async USB yea....and sure guys on gearslutz know nothing either. The truth is out there eventually

And my bad, my USB controller board runs a 10ppm clock, not 1ppm and yes it sounds way more focused than the stock one that musta been 30ppm back in the days but became more like +50 nowadays.

So that Rednet costs 2 grand and the mutec 1, that makes perfect sense to me and so does the extremely impressive completely subjective ranking. So much wisdow in this thread, broscience it ain't

 

You'll note, of course, that the quoted difference between any of them is extremely small?

You'll also note the irony of referencing subjectivity when your own claims are also COMPLETELY subjective.

No, wait, that'd require reading comprehension and basic logic.

Designed for internal use over very short connections. Requires special engineering considerations to not f**k-up when you start running at typical interconnect lengths (which does nothing to reduce cost or effectiveness).

Some do, some don't. Your referenced post flies in the face of engineering and common sense.

So, still not meeting spec then.

Might want to re-read the AES specs.

It's you that's quoting others and making statements towards implementation that it's pretty clear you don't understand. Especially if you're bringing up USB bus-clock performance as in anyway relevant to audio. Data either arrives fast enough to keep the DAC's USB receive buffer full, or it doesn't (and you get drop-outs). The USB bus-clock is irrelevant to audio. And the only clock-information relevant to the data on the DACs end in USB is a SYNC marker, intended to allow multiple units to reference a common time-base, that say's "play this at this time" and all do so correctly. It is in no way related to anything regarding samples fed to the converter.

--

How many times have you implemented AES, S/PDIF or USB?

 

Right, AES/EBU is using the exact same crappy clock extraction process as S/PDIF, the only difference is that it runs over balanced cables and allows for much longer lengths to be used. I'm sorry I don't have time to answer all your knowledge craving questions but I really thank you for your patience and kindness sharing all that non-broscience knowledge of yours, so to sum it up the bestest subjective sound quality can only be achieved with clock extraction via daisychained megabucks boxes. Dully noted and highly enlightening to say the least, thanks again

 

The bi-phase clock implementation not-withstanding, you're just demonstrating what I said earlier.

Having implemented all of these standards, in multiple ways, I'm not seeking "knowledge" from you. But if I was, of course you wouldn't have time to answer them because first you'd have a metric ass-load to learn.

Who's claiming this?

The best result I got was with one box, no daisy-chaining required.

Source clock stability and accuracy is a known requirement for S/PDIF precisely because of it's design. Not really a surprise that a better implementation yields both audible and comparatively easily measurable results. But since you're dodging the real question, and just throwing out meaningless phrases like "bro-science" - you're the one claiming clock differences in an packet-based decoupled asychronous protocol make an audible difference ... and throwing wonky cable requirements on top of it.

You're not even a GOOD troll ... /wave

 

I really must refrain from attempting to deal with this sort of self-contradictory troll-idiocy and just make more aggressive use of the "ignore" function.

Starting now ...

 

Right, looks like it's your lucky day as my google-fu skills are top notch today: http://repforums.prosoundweb.com/index.php?topic=12452.0

Clocking with AES can be done 2 ways, a "good way" and a "poor way".
The "good way" is to make sure that the AES signal DOES NOT CONTAIN AUDIO. The AES signal with no audio is often called "AES Black".

The "poor way" is of course to clock to an AES signal containing audio. The issue is due to the fact that having audio bits change next to the AES signal's "preamble" will efect the timing of the preamble. The preamble is the signal used to synchronize the AD under external clocking operation.

Exact same story as that gearslutz link I already provided that clock and signal should never be mixed on purpose, would you say that Dan Lavry is also clueless and needs to go back to AES school?

 

ROFL. Got your degree in trolling from the U. of Google-Fu eh?

 

Well, those subjective ranking lists based on nothing and S/PDIF & AES raving in 2017 really had it coming c'est la vie. You can't technically deny that clock recovery is just a terrible idea to begin with(and lemme tell you that Dan Lavry is no public amuser) but surely it all keeps bored OCD'ed audiophiles entertained as it gives them more toys to mess around with and rave about on public forums, talking as wealthy self-proclaimed experts and all that

 

Someone please dig @leescratchy a place in the How to Win Friends forum... A deep, deep hole, not the usual 6 feet one.

 

You realise all of that diarrhea you posted is with relation to using an external source as MASTER CLOCK?

 

I haven't seen any mention of using a discrete Word clock signal and anyway there would be no point in mixing a crappy embedded clock signal if this was the case but I'll let the big boys play, it makes so much sense to go USB > S/PDIF > hit & miss clock recovery > I²S when you could go async USB > I²S. And yes many DAC's also come with I²S inputs, this protocol wasn't meant to be transported via cables but it's still a way better option than S/PDIF & AES, you guys might wanna look it up and I certainly hope that your bowel motility will improve.

 

I hope your keyboard accuracy improves, and at another site. Perhaps Google-fu can better inform you on how DACs work.

N.B.: perchance you are the offspring of Sofa King and GUTB? Seems like a mix of them two.

 

Reclocking a signal that had its original clock recovered is a major crap shot but I bow down to your forum science expertise my lord

 

I know Dan Lavry. He is very smart, especially in converters. I've participated in sessions using his A/D and D/As. Had discussions about converters with him personally. He presents occasionally to our AES section meetings.
If you look further down his discussion from 2006 you reference, you will find this excerpt:
The issue of ASES black vs AES with signal applies when:
1. You are trying to extract a clock from an AES signal when trying to sync an AD to external clock.
2. The frequency locking circuitry (such as PLL - phase lock loop) is average or lower quality.

Having a bit of experience measuring converter jitter (please have a look at my technical measurements on this forum) I would like to note the difference between discussions of architectural preferences and practical implementations. The evidence demonstrates practical implementations can be very good even with a lesser architectural design. Practical implementation is very important as one scales a system. Studios tend to be very large implementations with cabling a sizable consideration.

 

OK thanks, fair enough but several designers have made very clear that the best scenario is to have the DAC outputting Word Clock and the DDC syncing to it, for that matter m2tech DDC's come with I²S output over cables and Word clock input: http://www.m2tech.biz/it/images/prodotti/evo-two-2.jpg

With this kind of sync, I'll be keen on believing that S/PDIF & AES can deliver but both signal and clock happily mixed together and relying on clock recovery and possibly PLL reclocking on top providing higher SQ than async USB & I²S over short cables give me zero faith.

I see no practical reason no drop 3 g's on magical USB gizmos when you can do things the right way to begin with, no ned to polish a turd just get a proper clock source already.

I stand by this quote, of course he doesn't have any $2K audiophool shiny box to sell: https://www.gearslutz.com/board/1788545-post2.html

 

This is one of the reasons I was asking the agitator if they'd ever actually implemented any of this stuff. My bet would still be "no". Never mind the misapplication of what they were quoting. I love that approach ... they can't substantiate something on their own, so they have to go quote something they apparently don't understand, are misapplying, or is only tangentially relevant. It's akin to adding 1 and 2, getting 5 and saying "See, I'm right!".

And I still think it's hilarious that said party was advocating for fiddly, OOS, USB setups as an appropriate alternative - especially the thing about the USB clock. Guessing that they've not read (or failed to understand) the UAC 2.0 spec as well, much less had to implement that.

On the upside, this little departure shows just how well the ignore function here works.

 

Sure thang, you built your own R2R DAC on a chip and it does magical clock recovery too I'm sure but in the real world many DAC engineers like to slap CS8416 because it supports both S/PDIF & AES up to 192kHz, which makes audiophools plenty happy because yeah 192kHz sounds so amazing lol(Dan Lavry said that 88.2 is the optimal sampling rate but what does he know again ^^).
Anyway, let's have a look at what CS8416 can do in 192kHz mode(PDUR=0):

They didn't dare giving any figure for 44.1kHz but it would prolly be in the 650ps region, no matter what audiophool DDC you'll use CS8416's clock recovery will give you those figures, yes even your megabucks femto clocked DDC. Might as well go back to 1ns Toslink at this point lol

It always cracks me up to see ppl spending fortunes to feed CS8416, they've been taught well by salesmen and forum shills and yes I'm well aware of WM8804 and so on but their PPL reclocking colors the sound quite a bit too.........hopeless situations call for hopeless dirty fixes, at this point anything goes.