[slwiser]

I have not seem this new device noted anywhere before.  It must be new.

This makes a great device only better.

http://www.hagtech.com/hagusb.html

[hagtech]

I kept getting requests for an XLR output version.  Some DACs just don't have the RCA input.  So I found a slightly larger box that the same board fits into.  Change a resistor value and output impedance is 110 ohms.  Of the few I have built, so far they work like a charm.



I also get requests for the optical TOSLINK output, but I refuse to do that, as it is a low performance consumer grade connection.  I just can't convince myself to downgrade performance and add jitter.  The HAGUSB was designed to produce a high quality output signal.  Yeah, I'm supposed to realize the customer is always right and that I should just make what they want.  But I can't.  It only works when it melds with my own personal beliefs and company philosophy.  I only want to design and sell high quality equipment.

jh

[analog97]

Yeah, I'm supposed to realize the customer is always right and that I should just make what they want.  But I can't.  It only works when it melds with my own personal beliefs and company philosophy.  I only want to design and sell high quality equipment.

Thank you for your adherence to the highest of personal standards. Looking forward to my Piccolo project!

[slwiser]

Jim are you going to update the Hagusb to have the new firmware that bypasses the windows kmixer completely at low level automatically?  I saw that this firmware can be license now.  It seems it would make the device even more bullet proof and killer than it is now.

[hagtech]

Hagusb to have the new firmware

The HAGUSB uses a hard-coded USB chip.  This new "licensable" firmware is for the TAS1020 processor that is used in the new Benchmark machine (and we all thought they had developed it!).  That's right, some other company of software gurus put this code together, and now they want to sell it to other companies. 

It would be a whole new product for me.  Haven't looked at the pricing yet, but I think it's way out of my ballpark.  Not something I could put into a half-kit.

I do have some interest in this, though.  Except I want it to work both ways.  I want the code to also have an upstream pipe that I can connect a 24/96 ADC to.  For something like the RIPPER2.  But the code does not do this.  They might be looking it.  At the moment, I'll just be watching to see which way they head.

jh

[slwiser]

Thanks for the update on the information about the firmware issue.

[dnewman]

BTW, last weekend I actually played around with a toslink with my
Chime.  I did this largely out of curiosity -- was it as bad as I've always
heard people claim?  Well, I certainly didn't like what I saw when
I put things up on an oscope.  There was definitely more jitter
as could be seen by simultaneously comparing the electrical and optical
outputs on the three sources I tried (a SqueezeBox 3, a Transporter, and
a Denon 2900).  I wasn't allowed to open the Transporter, but the other two
used transmitters from the ubiquitous Toshiba TOTX line.  (I'm not
sure if anyone else even makes the modules.)  My receiver was based
upon the Toshiba TORX177 receiver following Toshiba's recommendations
for using the device (i.e., I read the app notes).

Why the (considerable) extra jitter?  I suspect largely because of the
conversions from electrical to optical and then back again.  Likely
exacerbated by being an extremely low cost implementation of the
concept.  (By "low cost implementation", I'm referring to the Toshiba
modules and cheap consumer optical cables and not my specific
receiver implementation.)

I'm not prepared to say that I could hear a difference as I didn't
do much more then about 15 minutes critical listening, if even that.
Further, I don't know how much of the jitter was salvageable by the
HagDac's signal reclocking.  It may be that all of it was or perhaps
very little of it.  What would be an interesting test would be to have a
quality DAC for which the reclocking (i.e., jitter reduction) function
could be easily switched on and off.  That might make for a
nice, audible demonstration switching the reclocking on and off
as well as switching between the electrical and optical S/PDIF
inputs.

At any rate, my lesson learned was that toslink is a poor second choice.

[NewBuyer]

Thanks for making this product Jim! What a fine product is the HagUSB.

Hopefully an ethernet solution will also be available from you someday  . As you mentioned in an earlier thread, this would allow output timing to depend only on the local clock, instead of the variable output frequencies of different PC clocks. Additionally, ethernet connections also use pulse-transformers, so the S/PDIF output would still be isolated from the PC power supply. I continue to imagine a "HagNET" style product - wouldn't that be cool?

I would definitely buy a HagNET.

[krikor]

There was definitely more jitter
as could be seen by simultaneously comparing the electrical and optical
outputs on the three sources I tried (a SqueezeBox 3, a Transporter, and
a Denon 2900). 

I know this is off topic, but ... I've got two of the three sources you used (SB3 and Denon 2900) and I am considering getting my hands on the 3rd (Transporter).  I'm curious if you have ever done any listening and/or measurement comparisons of the coax (and BNC) digital outputs of those units, in particular the SB3 and Transporter.  Additionally, how does the AES/EBU output on the Transporter stack up against the BNC and coax?

I've been a bit dissapointed in most of the reviews I've found of the Transporter as none seem to evaluate the digital output in comparison to the SB3.

Thanks.

[dnewman]

Well, I cannot provide you with apples to apples comparisons of the
Transporter vs. SB3 other than to note that the digital coaxial output
(S/PDIF + RCA) on the Transporter does indeed seem to have less jitter
than a SB3 as seen on a Tektronix sampling oscilloscope intended for
doing clock signal analysis in digital circuits.  I won't cite the numbers
I observed as I have no training in taking such measurements.  Also,
my objective wasn't to compare an SB3 to a Transporter but rather to
compare an electrical S/PDIF signal reconstructed from an optical
TOSLINK signal to the original electrical S/PDIF signal used to generate
the TOSLINK signal.  That is, I was trying to see what damage, if any,
the conversion to and from TOSLINK caused.

So, if you're only going to use the boxes as a digital transport feeding a DAC
which reclocks the data anyway, AND you want to use either digital coaxial
or TOSLINK, then I don't think that a Transporter will outperform a SB3 at
your ears.   If you're doing a long cable run or otherwise are in an EMF noisy
environment, then the AES/EBU output of the Transporter serves a real use,
but I'm skeptical as to how useful it is in the typical home setting.  I've never
used the Transporter's BNC or XLR outputs.  However, I'm now curious as to
what the jitter looks like on the end of a 1 or 2m cable connexted to the XLR
output jack.  Think of it: you now have two signals with noise sources past the
point at which the digital signal was split into the differential pair.  Yes, you're
more resilient to EMF induced noise, but what's the nature of the other noise
sources and what impact do they have?

I -- or my wife -- happens to own a Transporter which we use with
a Chime.  Why given the incremental cost difference vs. a SB3?
Solely because my wife and kids like the convenience of having the physical
front controls on the unit.  They don't have to look for the remote nor
go to a computer screen in order to conjure up whatever music fits
their mood.  And for her, that was worth the extra $$$.  Me, I'm happy
with the SB3 in my office.

As to the analog outputs on the Transporter and SB3, I've never
bothered to critically compare the two.  I can tell you that my wife
and I prefer to feed our SB3 and Transporter through our Chimes
rather than use the analog outputs of the two devices.

Cheers,
Dan