Regen, Wow!

[the professor]

I used to think that too. If a $50 computer CD drive can read the ones and zeros bit perfect then why do we need to spend anything more on a transport or any cables or anything else . . . . . . it just doesn't make sense.

But, as I've heard differences over and over and over again on transports, cables etc. there is something to it. I don't care the "why" of it. It sounds different - sometimes better and sometimes worse - but it does sound different.

No clue on the Regen - haven't tried it, but "Everything Makes a Difference" in this hobby.

 

[FlexibleAudio]

Its ones and zeroes. It's discrete. It's exact. Either the ones and zeroes arrive in the same sequence or they don't. It's only when you convert to an analog signal that you can change it. I can send a gigabyte to China over the Internet and have it arrive bit perfect. No problem happens constantly. But I can't send bit perfect data to my asynch DAC from a computer 2 feet away? Sounds very wrong. Sanity test failed. Any improvement you are hearing is imagined. I can't prove it but you can't prove it either since sound quality improvements wrought by the regen are not measurable except by human interpretation (which is highly inconsistent and unreliable).

But with that said, I'll take two, they're cheap.

Jax,

As others are saying, this product's name doesn't do the best job of explaining its real value-added to SQ. What Swenson has done is focused on minimizing the impact of packet noise (in the USB's power supply and signal) on the dac's power distribution network which in turn reaches the sensitive chips in the dac input (PHY chips). He does this by using some reasonable science like localized grounding and new clean power at the signal interface. It will often improve the SQ of usb connections from dirty pc's and possibly even specialty audio designed decoder boxes (like your Aurender) even if they take proper power isolation and grounding steps at the source (depending on their level of sophistication). This part of Johns stuff is real.

Where I think John could be a little clearer in his marketing jargon is on two fronts: 1) where you are focused - the fact that bits is bits; and 2) his claims about impedance matching. "

"Regenerating" a bit perfect stream, all else held constant, yields a bit perfect stream; that's no big deal. Cleaning up the mess of a flawed interface (noisy usb) is a big deal and I credit the device for doing so. It accomplishes the same things others (Berkeley, PD, MSB etc., etc.) do in similar ways. To that end, the name "Regen" makes it sound more about the imperfect bits being regenerated as perfect bits than the noise being eliminated; its the latter that's important.

Regarding the claim about the unit "impedance matching" the incoming source to the dac, I don't think this is the best way to explain what is happening. No doubt the unit is taking fresh power and reduces the output impedance of the source at the signal interface, but this is a static event that does not change based on the dac to which its mated. The claim implies the regen has a magic feature that reads the input impedance of each dac and adjusts itself accordingly. If that is the case I would love to understand how this is accomplished. A better way to make the claim would be to say: the unit reduces output impedance for better pairing with a dac when long usb runs are required. Not only is the claim of "matching" a stretch but this issue is really not relevant for most sources unless you have a very long usb run.

So those are marketing issues. As far as the John's design parameters go, where I question the regen's overall sound improvement limitations versus other more sophisticated approaches relates mainly to the clock. John has decided the best way to limit packet noise is to re-clock the entire stream at the signal interface using the regen's own independent clock. This step appears to be counter to the entire premise of asynchronous usb where the PC's (or server's) clock is rendered irrelevant and a much higher precision clock in the dac runs the show. Does the regen not work asynchronously with the dacs's clock which in most cases is vastly superior to whatever John has put in this $147 device? This appears to be the case and, if so, it would create an extreme limitation to the ultimate potential of the unit.

I have not seen this point addressed. If it has been I apologize; as has been made clear I am a slow learner. But if the unit is not using a full asynchronous connection, I would equate this design to cutting off your arm because your thumb hurts. Why sacrifice asynchronous jitter control and all its glory to manage packet noise???? Aren't there much better ways? If this is true, the unit would tend to only help dacs with average clocks being fed by sources on the noisy end of the range, but that's about it.

Jax, I will be curious to learn of your findings.

 

[wisnon]

Dear Flexy,

Where have you been all day? I was was waiting to play idea tag. LoL. You made my day now.

I respectfully disagree somewhat with your explanation, for example clean power is NOT a primary objective, but it is a necessary condition to achieve the primary objective of a HIGH quality signal right up against the USB receiver that wont have cable length, etc to degrade it before it is received by the Dac's port. Also impedance matching is important as it also helps to lower total Dac impedance, which is a highly desirable state of affairs. To be honest, to really thrash this out and make sure we are not just talking at cross purposes, it would be ideal to have a face to face discussion, where typed words cant be mis-construed.

In any case, let me allow the Uptone guys to explain in their own words. I have posted many seminal JS rants here in the recent past that explain where he is coming from and shows that no-one else apparently is addressing the issues of USB in this particular way, ie SIGNAL quality and its ability to propogate noise into the Dac. JS is always careful to say that the PHY noise is never passed, BUT if SI is low, a lot fo NEW noise WILL be generated by the Dac's USB PHY section. All the Regen is about is avoiding as much propogation/stimulation as possible. Clear power, low jitter clock and even impedance matching aid in this, but the first 2 are not primary goals. The last one kinda is, as it does something else important which I alluded to above. He also played around with resistance on the 4 layer board and found a SQ sweetspot, so hence the AMBER evolution.

Let's hear from JS here:

To explain how the UpTone Audio USB REGEN works and why it is so effective with such a wide range of USB input DACs, we first need to define some technical terms and some problems inherent in USB audio interfaces—hopefully in not-too-technical language:

PHY: PHY is an abbreviation for the electronics that interface to the physical bus. PHYs exist in most every type of data interface (Ethernet, FireWire, optical, etc.) A USB PHY serves two primary functions: to convert the analog voltages used on the Data-plus and Data-minus wires into a digital format normal logic can understand, and to convert the high speed one-bit-at-a-time serial data stream into a slower parallel set of wires to be sent to the USB protocol engine (XMOS processor, FPGA with USB core, etc.). The lowly PHY chip is actually a tremendously noisy and complicated device containing multiple PLLs and clocking at various phases—and there is no such thing as an optimized-for-audio PHY. The PHY part of a DAC’s USB is highly susceptible to the condition of the USB signal, its "Signal Integrity" (SI).SIGNAL INTEGRITY: A high-speed USB signal runs at 480 mega bits per second, which is fairly high. SI is comprised of the rise/fall times of the signal edges, amplitude of the signal, noise sitting on top of the signal and jitter of the edges. Variations in any or all of these can decrease the SI. The computer determines this initially, and then it can get significantly degraded by running through cables and connectors.
The decrease in SI can be so large that it becomes difficult for the PHY to determine the actual bits. Thus the PHY contains several methods used to pre-process the analog signals in order to make it easier to determine the bits. When the SI is very good, the PHY can turn off the pre-processing steps and easily determine the bits. As the SI degrades the PHY turns on different parts of the pre-processing as needed. Each of these steps takes a fair amount of power to operate, thus creating noise on the power and ground planes. The more processing the PHY needs to use to determine the bits, the more noise is generated. Thus part of the packet noise is directly related to the signal integrity of the incoming signal. The higher the SI, the lower the noise.
PACKET NOISE: In a DAC the data packets coming in on the USB bus are not continuous—there is significant time in-between each packet. Thus the processing of these packets produces noise on the power supply and ground plane that come in bursts, and we refer to this as "packet noise". Since the rate of USB packets is 8KHz there are strong components of this noise in the audio band. This noise can cause jitter in clock oscillators, re-clocking flops, and DAC chips. It can also go directly into noise on the output of DAC chips.
Part of this noise is determined by the USB protocol engine (chip after the PHY) and is going to be constant for a particular DAC.
POWER DELIVERY NETWORK (PDN): In order for a power supply to properly respond to instantaneous load variations, it needs to have a low impedance over a very broad range of frequencies. For digital audio this is from low Hz to hundreds of Mhz range. The entire supply flow from mains AC to board layout and capacitors on the board play a role in getting this right. The process of frequency optimizing the PDN is something that is done in expensive high-speed network equipment, but is almost never done in consumer products, especially audio equipment. (And our experience with the REGEN points to this being quite important for digital audio.)
​

Okay, now that some definitions and issues have been set forth, let’s look at how the UpTone Audio USB REGEN addresses them.To recap the issue:
The lower the signal integrity (SI), the harder the PHY has to work, which produces greater packet noise. If the SI is very good, the packet noise from the PHY is less than that from the protocol engine. As the SI degrades the packet noise from the PHY can dominate.
Again, the packet noise consists of two parts: noise from the USB protocol engine and from the USB PHY. The protocol engine noise does not depend on the input signal quality, just the data, so its impact is always going to be the same no matter what is done with the input. The PHY is the part that actually connects to the electrical signals on the bus, ITS contribution to packet noise IS dependent on the quality of the input signal.
It is very important to keep in mind that all this is what happens INSIDE the DAC by its own operation, it is NOT noise on the USB bus that is somehow getting into the DAC as is commonly thought.
At this point there aren't any DACs that have been specifically optimizing their USB inputs for SI and impedance match, it's too new as a specific concept to design to. But the best DACs do optimize this to some degree, whether by trial and listening or as a byproduct of optimizing for something else.
So tell us how the darn thing works already!:
The REGEN is at its core a single-port USB 2.0 hub. All hubs actually contain two USB interfaces and a full-blown USB protocol engine. It is not just working at the analog level, it is actually receiving the data from the DAC, putting it in a buffer and retransmitting (and the other way for the packets from the DAC).
It uses a selected USB hub chip to create a new USB stream to deliver a very high signal integrity to the DAC's USB PHY, thus decreasing the PHY’s contribution to packet noise. It is called “REGEN” since it completely REGENerates the data signals that cables are messing up—it’s not just a re-clocking. Because it uses clean power and a low jitter clock, the output of the hub has low noise and low jitter. To be most effective, and to maintain best signal integrity and ideal impedance matching it is best positioned right at the input to the DAC, thus its small size, low weight, and included male>male USB ‘A’>’B’ adaptor.
The result is that the PHY in the DAC doesn't have to use any of its pre-processing circuit arsenal so the packet noise is as low as it is going to get.
Does the REGEN eliminate the need for a good USB cable and other computer optimizations?:
No. The hub chip inside the REGEN has its own PHYs and protocol engine, which themselves generate packet noise on ITS power and ground planes. So the REGEN itself is also sensitive to the SI of the signal fed to it, which is why good USB cables and specialty USB host boards feeding it still make a difference—maybe just not as much. A lot of time was spent on the design and board layout to minimize this packet noise but it is still there. The impedance of the "Power Delivery Network" (PDN) over a broad range of frequencies determines the amplitude of the packet noise produced by the hub chip. The REGEN’s frequency optimized PDN is what makes it such a good sounding source.
The ideal solution would be to figure out how to prevent all this noise from crossing out of the USB input system and getting into the DAC chip and clock. Unfortunately this is really tough and nobody has completely figured out yet how to do so. Thus every DAC ever built will have some level of susceptibility to external influences, some more some less.
The question everybody asks then is:
Well what about DACs that have full galvanic isolation after the USB system and reclocking on the DAC side? Unfortunately USB input noise of all sorts still makes it through to some extent and reaches the DAC master clock. Exactly how this works is complicated, John Swenson has written in-depth about this elsewhere [see Part 2 of our Q&A with John]. The upshot is that neither galvanic isolation nor re-clocking completely get rid of it. They help attenuate it some, but don't get rid of it.
The REGEN’s secondary function is to ignore the 5V USB bus power coming down the cable from the computer (or other host) and to provide—to DACs that require it—a very clean and isolated 5V supply. The REGEN has a separate ultra-low-noise regulator for this. (For DACs that don't use the 5V wire, that regulator in the REGEN is not used for anything.)
Lastly (unlike another hub-chip based device out there), the UpTone REGEN uses a 4- layer board, primarily to allow a proper impedance match. With a standard thickness 2- layer board it is impossible to attain a proper impedance match to the hub chip. The pins on the chip are small and close together, this necessitates very thin board traces. With a two layer board the distance between ground plane and these traces (this is called a differential micro-strip configuration) produce an impedance that is much greater than the spec. With a 4-layer board the ground plane can be much closer to the top layer, and that allows for appropriate impedance with the very narrow traces. The REGEN also uses surface-mount USB jacks that allow for appropriate trace width and spacing to continue the impedance matching through to the USB jacks. The result of this is that there will be very minimal reflections at the REGEN side. Even if the DAC does not have good impedance matching—which is pretty common and which WILL cause a reflection at the DAC end— it will be absorbed at the REGEN because of the proper impedance matching.

Read more at UpTone Audio USB REGEN | AudioStream

 

[wisnon]

From Alex:
Glad you like the effect of the hub chip in the Corning USB cable. That is essentially what John Swenson has done for our new USB REGEN device. It is a carefully chosen USB hub chip, plus ultra-low-noise regulators, plus a low jitter clock--with exact impedance matching at its output--meant to plug directly into the DACwithout any cables.


And from John S:The Wyrd and the regen are conceptually similar from an upper level standpoint, they are very different in implementation and motivation for the development.

From reading what Schiit has posted it seems that their motivation was providing a clean power supply and secondly regenerating the data, whereas my motivation was providing the highest signal quality I could, and secondly providing very clean power.

Some of the differences are:
The regen has a much lower jitter clock feeding the hub chip, which will provide lower jitter on the data.

The regen uses a 4 layer board, primarily to allow a proper impedance match. With a standard thickness 2 layer board it is impossible to attain a proper impedance match to the hub chip. The pins on the chip are small and close together, this necessitates very thin board traces, with a two layer board the distance between ground plane and these traces (BTW this is called a differential micro-strip configuration) produce an impedance that is much greater than the spec. With a four layer board the ground plane can be much closer to the top layer which allows for appropriate impedance with the very narrow traces. The regen also uses SMD USB jacks which allow for appropriate trace width and spacing to continue the impedance matching through to the USB jacks. The result of this is that there will be very minimal reflections at the regen side. Even if the DAC does not have good impedance matching (which is pretty common) which WILL cause a reflection at the DAC end, it will be absorbed at the regen because of the proper impedance matching.

The regen has a frequncy optimized Power Delivery network (PDN), which turns out to make a very significant improvement in SQ. This is quite a technical subject, WAY beyond what I can post here, but here is the mile high summary:

In order to properly respond to the load variations of what the supply is powering, it needs to have a low impedance over a very broad range of frequencies. For digital audio this is from low Hz to hundreds of Mhz range. The entire supply flow from mains AC to board layout and capacitors on the board play a role in getting this right.

The regen is what got me focusing in on this. I was testing the first prototype and was seeing some noise on the supply right at the hub chip power pins that shouldn't be there. After a lot of detective work I traced it down to some frequency ranges of the PDN that were much higher impedance than they should be. I included a fix for this in the second version. With this I couldn't detect the noise any more, and it sounded much better, but Alex was still not super thrilled with the SQ. I then did a mathematical analysis of the PDN and found another frequency range that had a higher impedance than it should, made a fix for this, and sent the result to Alex, he was thrilled, this was much better than anything he had heard before.

This process of frequency optimizing the PDN is something that is done in expensive high speed network equipment, but is almost never done in consumer products, especially audio equipment. But the experience with the regen seems to point to this being quite important for digital audio. I have subsequently tried some of this on some DACs and seen marked improvement in SQ, so it looks like this might be a significant area to look into.

The whole reason I started thinking about a regen was the USB cable threads, after a lot of experimentation and thinking about it, I came to the conclusion that the signal integrity at the DAC was what was probably the difference between cables. Thus a device designed to regenerate the data signals. Because the whole purpose was to regenerate the signals that the cables were messing up, the regen device had to be right at the input to the DAC, thus it needed to be small and low weight.

One un-anticipated benefit to the frequency optimized PDN, is that the noise on the VBUS output is much less sensitive to load transients than other implementations. So if the DAC IS bus powered, that brings even more improvement.

Well there it is, the primary reasons the regen hasa better implementation than other devices.

John S.

 

[wisnon]

I personally LOVE this post Paul and I am pretty sure you must have read it:

Originally Posted by JohnSwenson
Due to the large number of questions I'm not going to quote each one here, I hope I cover them all.

The isolation between computer and DAC was not a primary focus of what I am talking about now. Test I did seem to show this is not as big an issue as many previously supposed.

This post is primarily about the impact of the PDN on the generation of PS noise at sensitive chips in a DAC(main oscillator, DAC chip). In particular how a packetized data delivery (USB, Ethernet) significantly exacerbates this. Primarily because the packetized system produces current through the PDN with a much greater bandwidth than non-packetized systems (say I2S). Producing PDN to work well over this wide bandwidth is MUCH harder than for a non-packetized system.

On the question of WiFi: it is also a packetized system, and because of all the processing going on in WiFi, probably much worse than straight wired Ethernet.

On isolation, I have been including full isolation between digital sections and mixed signal sections for many many years. I do not use optical isolators, I do not like them at all, I prefer the GMR (Giant Magneto Resistive) isolators made by NVE. I think they work way better than opto isolators.

The important question here is how come an isolator doesn't completely fix things, it seems at first glance that having completely isolated power networks for the digital side and the mixed signal side (I'm calling it mixed signal because there are digital signals (I2S data, clocks) AND analog signals (output from the DAC chips) in the same power domain) should prevent PS noise from going between them. If the power domains were truly isolated they would, BUT the domains are NOT completely isolated, the data is going between them! This is the part that is usually forgotten in these types of discussions.

I hope I can convey what is happening here, let's follow a pulse through an isolator between domains and see what happens. Let's assume a real "dirty" digital side, a lot of ground plane noise and power supply noise, and noise riding on top of the digital signal. Lets look at the isolator, it has power and ground connections on the "dirty" side that run the driver that produces the whatever crosses the "barrier" (light, magnetic field, radio waves, whatever). The noise also modulates the "threshold" looking at the input signal. These and the noise andjitter in the signal all add up to a pretty large amount of variation in the field crossing the barrier.

On the other side of the barrier you have a much cleaner supply driving the receiver circuit, but the noisy field is going to cause a current in the receiver. Thus noise on the dirty side is going to cause current noise on the clean side as well. The isolator designers try and make them so the physical properties of the receivers have some form of thresholding so this transmitted noise is decreased, but a fair amount still gets through, and it is greater at the low frequency side. But that is not all, the data, the signal you WANT to cross the barrier, also causes current to flow through the PS pins of the clean side of the isolator, and that signal has a lot of jitter on it by now.

When the packet noise on the dirty side of the barrier is low, the current noise of the isolator will be lower, when the packet noise is high, the current noise of the isolator will be high. So even though the power supplies are completely separate, packet noise on the dirty side can still make it through an isolator and show up as current noise on the "clean side". If the PDN is very low impedance over a very wide bandwidth this current noise will produce very little voltage noise. If the PDN is not so great, there will be some significant voltage noise. It usually will be reduced from what it was on the dirty side, but still definitely there.

Yes putting a whole tracks worth of data in ram, shutting down the packet interface, and grabbing the data out of ram at the audio sample rate should help this, but this is frequently done by a processor and it's memory, that processor is usually producing it's own set of current noise which can cross the barrier. To be really effective it would take a system where the source (whatever it is) fills up the buffer then completely shuts down, nothing drawing power AT ALL from then on, the only thing drawing power is the counter walking through the ram and the ram itself. You definitely would want a simple ram structure, not something like a DDR3 DIMM which has all kinds of stuff going on all the time. The data from the RAM goes over the isolator and on to the DAC chip. This would probably be a very effective isolation scheme, but I don't think anybody has actually ever implemented this.

I have been doing some more experiments on this in the last week and have some results to share. I was working with the USB regen Alex mentioned, with the first version I was able to clearly see the packet noise on a scope. I made a new version with an improved PDN, this seemed to work, I could not see any packet noise any more, noise was still there but I could not discern any modulation due to the packet frequency. It sounded significantly better. Later I did some crude PDN analysis and discovered there was a raising in the impedance over a certain frequency range. I figured out I could fix this by adding a single capacitor in the right place. I soldered in that cap and started listening and was startled in the magnitude of the improvement in SQ. The noise looked identical with and without the capacitor, the sound significantly improved.

So I think I am on the right track, but it looks like I have already gone beyond what the simple measurements I was doing could detect. Next is to do these tests with the spectrum analyzer, it will probably be able to detect the packet noise buried in the over all noise floor.

I hope that answers some of the questions.

John S.

 

[bzr]

Christ!

 

[wisnon]

Its been a long winding road to figure out what these guys are doing, but they seem to be on the right track from what I am hearing from the dvice itself (with ONLY the SMPS so far) and the logical basis upon which they are advancing.

Again, these are still only working hypotheses, but they are panning out big time.

 

[FlexibleAudio]

Jax,

As others are saying, this product's name doesn't do the best job of explaining its real value-added to SQ. What Swenson has done is focused on minimizing the impact of packet noise (in the USB's power supply and signal) on the dac's power distribution network which in turn reaches the sensitive chips in the dac input (PHY chips). He does this by using some reasonable science like localized grounding and new clean power at the signal interface. It will often improve the SQ of usb connections from dirty pc's and possibly even specialty audio designed decoder boxes (like your Aurender) even if they take proper power isolation and grounding steps at the source (depending on their level of sophistication). This part of Johns stuff is real.

As far as the John's design parameters go, where I question the regen's overall sound improvement limitations versus other more sophisticated approaches relates mainly to the clock. John has decided the best way to limit packet noise is to re-clock the entire stream at the signal interface using the regen's own independent clock. This step appears to be counter to the entire premise of asynchronous usb where the PC's (or server's) clock is rendered irrelevant and a much higher precision clock in the dac runs the show. Does the regen not work asynchronously with the dacs's clock which in most cases is vastly superior to whatever John has put in this $147 device? This appears to be the case and, if so, it would create an extreme limitation to the ultimate potential of the unit.

I have not seen this point addressed. If it has been I apologize; as has been made clear I am a slow learner. But if the unit is not using a full asynchronous connection, I would equate this design to cutting off your arm because your thumb hurts. Why sacrifice asynchronous jitter control and all its glory to manage packet noise???? Aren't there much better ways? If this is true, the unit would tend to only help dacs with average clocks being fed by sources on the noisy end of the range, but that's about it.

For goodness sake Normy-Poo that was not necessary. Of course I have read John and Alex's public stuff. It is essentially what I said to Jax in the two simple bold sentences in the first paragraph above.

The only interesting part of those missives is what's missing. An admission that the regen is not asynchronous and, as such, its clocking function is not performed by a far superior dac clock but rather the clock he put in his $147 device. He and you still do not answer the seminal question I asked in this regard because the answer is clear. He relocks using the cheap regen clock as opposed to properly addressing jitter with a high end dac clock. This is why on a net basis some find benefit from the regen and some don't. You get a quieter signal but likely with a much worse jitter condition depending on the quality of your dac clock. He has indeed cut off his arm because his thumb hurt. This only makes sense if your thumb really, really hurts.

 

[wisnon]

Flexy my man,

Its for the benefit of all, not just you.

The Regen is regenning the SOURCE signal and THAT is the clock to compare to, not the Dac clock. The Dac can still async against the Regen clock, but i am sure you agree that the best possible signal hitting the Dac's USB interface is where its at, no? Regen is not overrideing async and I dont know why you would think that...

I am serious about a face to face being efficient as we dont always seem to hget what the other says...

 

[FlexibleAudio]

Flexy my man,

Its for the benefit of all, not just you.

The Regen is regenning the SOURCE signal and THAT is the clock to compare to, not the Dac clock. The Dac can still async against the Regen clock, but i am sure you agree that the best possible signal hitting the Dac's USB interface is where its at, no? Regen is not overrideing async and I dont know why you would think that...

I am serious about a face to face being efficient as we dont always seem to hget what the other says...

Well Normy-Poo-Poo-Pa-Doo here is where your huge brain needs to help a slow learner out. When an asynchronous connection is made the clock in the source (pc, server, etc.) goes to sleep and does nothing. In this case that would be the clock in the regen. By definition (of JS) that is not happening as the clock in the regen is re-clocking the signal which implies a synchronous relationship with the dac, not asynchronous. This is my point. As such, the regen looses all of the benefits of a low jitter asynch connection in exchange for reduced noise ergo my analogy to cutting off your arm. Let me try to say it in other ways to help with my troubled communication skills. It is like:

----cutting off your nose to spite your face

----throwing the baby out with the bath water

----taking one step forward and two steps back

Is this helping???? BTW, I don't do the face to face thing. As you can tell from my posts, I am a shy and meek person. Large brained people frighten me. Thanks for the invite though.

 

[wisnon]

Hehehehe

Flexy,

I wholeheartedly disagree and think you are very wrong here. Too much to going now and I have to go rest my tired brain, worn out from the banter here.

Perhaps if you reexamine your own post, you will see the flaw in your argument...hint Regen is the new source!

 

[FlexibleAudio]

Hehehehe

Flexy,

I wholeheartedly disagree and think you are very wrong here. Too much to going now and I have to go rest my tired brain, worn out from the banter here.

Perhaps if you reexamine your own post, you will see the flaw in your argument...hint Regen is the new source!

Good gosh Norman that is my point. The only way a connection can be asynchronous is if the clock in the source is idle. By definition the clock is active in the regen. If you are serious you need to explain how black is now white and east is now west. Again, if the clock in the source is actively clocking the connection is synchronous, not asynchronous. Its that simple. You always pick one of two reactions when you are stumped: either attack with ad hominems and non sequiturs or run and hide cuz "its too much to explain now." If I am wrong please just explain where. You still refuse to go on the record regarding i2s' superiority over a usb connection or admit a DHT is not flat from 20hz to 20khz. Its the same thing all over again.

 

[wisnon]

OK, no more kidding Paul, as I dont want you getting a heated collar. I see you want a serious discussion, so I will make an exception and indulge in a little typing (which you know I hate- as I hunt and peck with 3 fingers). Please excuse the many typos.

My understanding is that the Regen is indeed NOT an impediment to asynch operation and that its the DAC's USB receiver implementation that determines the operational mode. The REGEN is no different to the original source and it's not the source that determines the USB mode, ie Adaptive, Synch or Async, rather its the Dac port. Hence, I cannot see your argument about baby and bath water in regards to the clock quality in the Dac. There is ALSO a clock in the Dac's USB that control this as opposed to the MASTER clock for the Dac chip in some Dacs. As to the clock relationship in a Digital converter, between master clock and USB PCB clock, that seems to have a myriad of implementations and is above my pay grade (I need a bigger brain for that, LoL).


From here: http://www.silabs.com/Support Documents/TechnicalDocs/usb-audio-simplified.pdf

Asynchronous Mode

[FONT=Arial,Arial][FONT=Arial,Arial]For asynchronous operation, the sink provides explicit feedback to the source. Based on this feedback, the source adjusts the number of samples that it sends to the sink. Figure 1 illustrates asynchronous mode with an analog output device.


[/FONT][/FONT]Figure 1. Asynchronous Mode

[FONT=Arial,Arial][FONT=Arial,Arial]This feedback mechanism accommodates source/sink clock mismatch without requiring the sink device to implement PLL hardware to synchronize with the host clock.

[/FONT][/FONT]Figure 2. Buffered System to Support Asynchronous Mode


Figure 2 shows a buffered system for a 48 kHz sampling rate. Initially, the host starts streaming data at 48 samples every USB start-of-frame (SOF) operation, which occurs each millisecond. However, if the device’s buffer begins to approach the full or empty condition due to clock mismatch, the device can request that the host send more (49) or fewer (47) samples so that buffer overrun or underrun does not occur. This method is implemented in Silicon Labs’ CP2114 USB-to-I2S digital audio bridge device. The Audio Device Class is supported by the CP2114 device without any additional software development.

[FONT=Arial,Arial][FONT=Arial,Arial]
Synchronous Mode [/FONT][/FONT]For synchronous operation, the source and the sink use implicit feedback, and clocks are locked to the USB SOF. The sink device must synchronize with the USB SOF as shown in Figure 3.

 

[wisnon]

Ad hominems Paul? Come on! I dont recall doing that. If I say you are WRONG, its about an action, not about the person's (your) character.

I see you have made a leap and said I declared you stupid. I dont think I EVER did that. I will go on record and say publicly that I DONT think you are stupid at all (far from it), in fact I think the reverse, but I do think you are wrong from time to time in SOME things (as I am too).

With that out of the way, lets get to i2S and DHTs. I am NOT convinced of the TOTAL superiority of it over USB, though I agree it has very important natural advantages, and perhaps that route is a quick and dirty way of attempting SoTA in PCM. For SoTA DSD I dont think its any better really and even for PCM, the gap with current SoTA USB is negligable. We can agree to disagree here. I have my reasons and you have yours.

For DHTs, in isolation what you say is likely true, but its too general. DHTs are normally used in power amp settings and there their characteristics wrt to SQ is well documented. Also yes, the tube specs are very well known. However, so far based on current empirical evidence, when used in a VERY low power environment like the DAC, with the additional variability of wildly different rectifier characteristics (from high to low Voltage drops and plug in SS rectis for $10 apiece), the SQ characteristics change again. So yes, while it may not be as linear as a $200 SS Chinese Dac, many like me dont care as its linear enough (certainly not rolled off, nor necessarily wolly bass - try a vintage metal base Philips GZ34, for example) and the combo of output and recti tubes can make it virtually anything you want. Many like vinyl more than digital despite the specs and I can see their point.

Then there is the matter of the Balanced DHT Dac. I still need to confirm for myself, BUT reports from trusted pals from BOTH sides of the Pond tell me that the impact on the Sound stage is NOT something that they have ever heard replicated by SS Dacs, so there are many characteristics in play, in terms of suitability. Even the Noise floor comparison where top quality SS has the natural advantage may be blunted by the diufferential summator in the Balanced DHT. So there is much to play for and with all the refinements from all the manufacturers, its all good. We get to pick our favourite poison.

Final point re the REGEN and why different feedback on its effectiveness in some dacs. The Lampi is the Dac that seems to have to have the most variation in opinions, though some of that is due to much of that based on the Green vs the Amber. Your assertion re: the master clock would not apply to Lami as Lampi does not reclock internally and the Amanero manages the clocking for both PCM and DSD and operates in async mode. This would be the opposite to what you were proposing.

My thinking is that the system setup has more to do with the level of success in introducing Regen. Electical connections, grounding, power quality, use of cables, PSU to the Regen, type of Dac USB port, bus powered USB or not and all other combo of factors that make it unpredictable to know in advance. i admit its just a guess.

I hope this missive is satisfactory enough for you...even as I suspect, you will still have profound disagreements.

 

[jkeny]

Good gosh Norman that is my point. The only way a connection can be asynchronous is if the clock in the source is idle. By definition the clock is active in the regen. If you are serious you need to explain how black is now white and east is now west. Again, if the clock in the source is actively clocking the connection is synchronous, not asynchronous. Its that simple. You always pick one of two reactions when you are stumped: either attack with ad hominems and non sequiturs or run and hide cuz "its too much to explain now." If I am wrong please just explain where. You still refuse to go on the record regarding i2s' superiority over a usb connection or admit a DHT is not flat from 20hz to 20khz. Its the same thing all over again.

Don't be confused by there being a clock in the Regen device. In asynch USB there are 3 clocks - a USB clock (usually a multiple of 12MHz) - two audio clocks (one for 44.1KHz audio family & one for 48KHz audio family). It is the audio clocks that are the master clocks in asynchronous USB - whichever one is enabled is used as the master clock to control the fillrate of the buffer in the DAC. The whole asynchronous system works by monitoring this buffer & sending signals back to the PC to tell it how much data to send in the next USB packet - in this way the buffer is kept approximately half-full at all times. The data in the buffer is clocked out by the audio clock & processed by the audio chips in the device. So this is how asynchronous USB audio works.

The USB clock (12Mhz or multiple) just controls the timing of the sending of USB packets, not the amount of data in the packets.

The Regen is a simple USB hub. All USB hubs operate as a two way staging post for the USB signal - they sit between a host & a device, receiving & sending USB signals in both directions. The signals are USB received & as part of the sending process are regenerated prior to being sent. The "new" USB clock in the Regen is used in the same way as all USB clocks - to ensure the correct timing of the packets - it has no part in the asynchronous function of a USB device - that is achieved by the USB signalling that is being sent back & forth between host & device (passing through the Regen).

Hope this clarifies?

 

[FlexibleAudio]

Don't be confused by there being a clock in the Regen device. In asynch USB there are 3 clocks - a USB clock (usually a multiple of 12MHz) - two audio clocks (one for 44.1KHz audio family & one for 48KHz audio family). It is the audio clocks that are the master clocks in asynchronous USB - whichever one is enabled is used as the master clock to control the fillrate of the buffer in the DAC. The whole asynchronous system works by monitoring this buffer & sending signals back to the PC to tell it how much data to send in the next USB packet - in this way the buffer is kept approximately half-full at all times. The data in the buffer is clocked out by the audio clock & processed by the audio chips in the device. So this is how asynchronous USB audio works.

The USB clock (12Mhz or multiple) just controls the timing of the sending of USB packets, not the amount of data in the packets.

The Regen is a simple USB hub. All USB hubs operate as a two way staging post for the USB signal - they sit between a host & a device, receiving & sending USB signals in both directions. The signals are USB received & as part of the sending process are regenerated prior to being sent. The "new" USB clock in the Regen is used in the same way as all USB clocks - to ensure the correct timing of the packets - it has no part in the asynchronous function of a USB device - that is achieved by the USB signaling that is being sent back & forth between host & device (passing through the Regen).

Hope this clarifies?

Thanks Jkeny. Your first two paragraphs are consistent with what my my understanding has been. What I am trying to clarify is whether the regen maintains an asynchronous connection or whether the clock that the literature refers to is in fact an audio clock (like a clock in traditional spidf transport). If the regen is in fact a USB hub then its simple and you have answered the question (it stays asynchronous), but I can not determine this from the literature and in fact the literature leads me to believe the clock in the regen is an audio clock. They stress its low jitter characteristics so intensely it makes me think it is more than a simple usb clock. That is my question. So I ask, do you know definitively that the regen is a usb hub or are you assuming this is the case? If yes, how have you determined this?

 

[jkeny]

Thanks Jkeny. Your first two paragraphs are consistent with what my my understanding has been. What I am trying to clarify is whether the regen maintains an asynchronous connection or whether the clock that the literature refers to is in fact an audio clock (like a clock in traditional spidf transport). If the regen is in fact a USB hub then its simple and you have answered the question (it stays asynchronous), but I can not determine this from the literature and in fact the literature leads me to believe the clock in the regen is an audio clock. They stress its low jitter characteristics so intensely it makes me think it is more than a simple usb clock. That is my question. So I ask, do you know definitively that the regen is a usb hub or are you assuming this is the case? If yes, how have you determined this?

Yes, it uses a USB hub chip as the main active device (the device that regenerates the USB signal) - it's in the posts of Alex & John on CA forum.

I haven't seen the emphasises in the literature on the low jitter aspect of this clock that you perceive - maybe it's just a perception? However, I would imagine that the quality of this USB timing clock plays some role in the sound quality (just don't know how big a role)?

 

[wisnon]

Thanks Jkeny. Your first two paragraphs are consistent with what my my understanding has been. What I am trying to clarify is whether the regen maintains an asynchronous connection or whether the clock that the literature refers to is in fact an audio clock (like a clock in traditional spidf transport). If the regen is in fact a USB hub then its simple and you have answered the question (it stays asynchronous), but I can not determine this from the literature and in fact the literature leads me to believe the clock in the regen is an audio clock. They stress its low jitter characteristics so intensely it makes me think it is more than a simple usb clock. That is my question. So I ask, do you know definitively that the regen is a usb hub or are you assuming this is the case? If yes, how have you determined this?

Did you READ my posts #103 and 104?
I have told you I hate typing, and since you implored me to answer...please do read what i type:

From JS: The REGEN is at its core a single-port USB 2.0 hub. All hubs actually contain two USB interfaces and a full-blown USB protocol engine. It is not just working at the analog level, it is actually receiving the data from the DAC, putting it in a buffer and retransmitting (and the other way for the packets from the DAC).

The lowly PHY chip is actually a tremendously noisy and complicated device containing multiple PLLs and clocking at various phases—and there is no such thing as an optimized-for-audio PHY. The PHY part of a DAC’s USB is highly susceptible to the condition of the USB signal, its "Signal Integrity" (SI).SIGNAL INTEGRITY: A high-speed USB signal runs at 480 mega bits per second, which is fairly high. SI is comprised of the rise/fall times of the signal edges, amplitude of the signal, noise sitting on top of the signal and jitter of the edges. Variations in any or all of these can decrease the SI. The computer determines this initially, and then it can get significantly degraded by running through cables and connectors.
The decrease in SI can be so large that it becomes difficult for the PHY to determine the actual bits. Thus the PHY contains several methods used to pre-process the analog signals in order to make it easier to determine the bits. When the SI is very good, the PHY can turn off the pre-processing steps and easily determine the bits. As the SI degrades the PHY turns on different parts of the pre-processing as needed. Each of these steps takes a fair amount of power to operate, thus creating noise on the power and ground planes. The more processing the PHY needs to use to determine the bits, the more noise is generated. Thus part of the packet noise is directly related to the signal integrity of the incoming signal. The higher the SI, the lower the noise.

 

[Rufus McDufus]

opcorn:

 

[wisnon]

Yes, it uses a USB hub chip as the main active device (the device that regenerates the USB signal) - it's in the posts of Alex & John on CA forum.

I haven't seen the emphasises in the literature on the low jitter aspect of this clock that you perceive - maybe it's just a perception? However, I would imagine that the quality of this USB timing clock plays some role in the sound quality (just don't know how big a role)?

Correct, and I have already reposted all that stuff from CA and Audiostream here in posts 103 and 104. I feel like we are going around in circles! However, if we finally get clarity for everything, it will be worth it.

Dac still does it Async thing, but Regen also does its own buffering to ensure high SI entering into the DAC's Async operation.

The reason for the low jitter clock in the Regen is that Jitter is a component of SI and he wants his interim signal to be as good as reasonably possible before entering the Dac's ecosystem. Could he have used a better clock? S_U_R_E! Indeed the CA poster from Northern Germany (HenSch) did a $600 NEUTRON STAR clock mod on his Regen and claims a very significant improvement. However his mod is clucky and costs WAY more than the Regen itself!

So yeah, JS and ALEX could do a $1k SuperRegen, but PoC was the $175+$8 shipping cost Regen (not $147- as stated here). Now that its market proven, they could do the Bugatti version, but unlikely from my PoV (too many hot projects in the works).