USB Audio Gremlins Exposed: Beyond 1s and 0s, by iFi Audio

and this device......
 
http://www.musicdirect.com/p-364758-ifi-ipurifier-2-inline-usb-audio-conditioner.aspx
 
 
discuss?
 

Having formerly worked as an engineer with communication protocols, I get peeved when I sense a lack of accuracy when describing such... Too many hours coding to the wrong specification can do that to you...
 

As far back as early 2001, computer-based audio with asynchronous USB audio proved it was possible to outperform SPDIF and/or AES-EBU based ‘cookie cutter designed’ systems.
Read more at http://www.audiostream.co...io#i0bBfzyOWF1WAcyW.99

 
This is what's called blowing smoke up people's...nevermind
 
I'll take a synchronous protocol like AES3/SPDIF/Toslink over an asynchronous polling protocol like USB any day.
 

It must be understood that USB audio devices (and USB video streaming) have much stronger requirements for USB hardware and software layers than any other USB devices, such as printers, hard drives or flash drives.
Read more at http://www.audiostream.co...io#i0bBfzyOWF1WAcyW.99

 
Heh, you transfer audio data asynchronously (USB) at regular intervals - sort of a noncommittal synchronicity termed 'isochronous', if it can be described that way. It almost is, but it just ain't synchronous. It can never be as accurate as a synchronous protocol.
 
The rest of the article goes on a bla-bla about signal quality, which can affect anything on the USB bus. It's simply more apparent with audio - if it is at all.
 
Bits are bits.
 

What's in the box?
 
There are no details about what they're actually "doing" to the digital signal.
 
blowing smoke - yep.  
 
I agree with Super G - I've done a lot of work to an incomplete or incorrect spec as well.  doesn't mean work wasn't done - it just didn't produce the REAL desired results!
 
 

SuperG
Having formerly worked as an engineer with communication protocols, I get peeved when I sense a lack of accuracy when describing such... Too many hours coding to the wrong specification can do that to you...
 
...
 
Bits are bits.

True. As long as all of the bits get from one end to the other.
 
After two years working as an asst. crew chief on the Neutrino beam line at Fermilab National Accelerator Laboratory, I spent the next 20 years doing SCADA (Supervisory Control And Data Acquisition) over radio. I designed solar-powered master and remote telemetry units (MTUs and RTUs), and then went on to run the systems engineering department.
 
One day, while walking down the hall, I observed two design engineers with their hands in their pockets, staring at the prototype of a custom RTU they were developing for Amoco Pipeline Co (after having been given $750K to do the work). They had a signal analyzer hooked up to it, but their eyes were as blank as the analyzer's display. I stepped in and asked them "what's up?". Well, apparently, they had signal on one card, but not the other that was connected to it by a 40-pin ribbon cable. They just couldn't understand why there was no signal on the far side of the cable.
 
I took one look at their schematic, started laughing, walked out and headed to my old boss' office to tell him he had two morons working for him.
 
They were trying to drive the address and memory busses directly from the CPU chip with no buffering drivers.
 
Cables and connectors can act like chokes (inductors). Square wave (ones and zeros) in. Tiny little rounded bumps out.
 
For a bit to be a bit, it's got to get to the far side in such a condition that it can be decoded correctly.
 
If you've got a crappy cable, it's just not going to work...and you'll know it, no problemo.
 
I don't need a USB audio conditioner. I need a DAW audio improver!

PRML - Partial Response Maximum Likelihood - is a methodology used to interpret "digital" from an analog medium such as a HDD drive. This also allows for some interesting tricks for data writing/reading. In reality, digital won't be a perfect step function even at creation which is why it relies on large thresholds and a clock. The receiver is just as important as the transmitter and in most cases transmission losses are accounted for in design.

SuperG
PRML sounds a lot like removing DC bias. I've had to deal with receiver sections that tended to bounce around a bit after a transmission. Since a most detection routines focus on the zero crossover point, you don't really care what the amplitude is - but any bias in the signal and all bets are off.
 

 
Way more black magic than that. Removing DC bias for digital signals is generally simple and has been done on all computer stuff since forever, usually with 8b/10b encoding. You take each 8 bits of data and encode it in to a 10-bit word. There are multiple 10-bit words for each 8-bit payload, with different 1/0 configurations and so by varying what you choose you can maintain 0 DC on the line. Ethernet, PCIe, etc all used this. Newer versions tend to use more complex encoding schemes like 64b/66b (10 gig net) and 128b/130b (PCIe 3 and USB 3.1) which use a complex polynomial scrambler to generate the data. Same idea, less overhead (though also a bit less rigid controls on DC offset).
 
So, PRML, this is largely a technology seen on magnetic disks and tape, though other things use it. What you do is rather than trying to write out binary data in a simple fashion where a value (voltage level, magnetic flux, whatever you are using) over a certain level is a 1 and under another level is a 0, you instead produce a fairly complex analogue waveform by just doing your best to modify what's there. When this gets read back in it looks at the wave it has and figures out based on the transition what is the maximally likely data sequence that corresponds to that wave. Sound like the kind of thing that would work for crap and you'd use to recover a bit of degraded data but actually is extremely reliable.
 
The net effect of PRML (or rather EPRML these days) is that you can have a much weaker signal level, and much more noise, and still get data out of it reliably. In terms of harddrives, it allows for more dense data storage. 

Also in terms of "active USB cable" all that is is a cable with a 1-port USB hub in it. You can get them extremely cheap at Monoprice, if you so desire.

So if I get all this right, as long as I hear audio at the receiving end, my cable's good. If I don't, my cable may be bad.
 
Replace with Ethernet. Why isn't Ethernet being developed more for audio?

bitflipper
Audio over USB is a bit of a kludge, as it was not designed for real-time data. But Ethernet is even worse. Its reliability comes from being able to re-send munged data, receive packets out of sequence, and find alternate routes. None of that helps much with audio, where getting the data in a timely manner supersedes even data quality.

I have always thought that USB was designed to send (more or less) real-time data.
And for Ethernet: it can solve collisions but that can be hardly called re-sending data, it supports no packet sequences (without touching Jumbo frames topic) and so it does not know which packets are out of it, and I would really appreciate in case someone can point me to alternate routes supporting Ethernet device. Are you meaning TCP/IP infrastructure?
 

I'd always felt that the main issue with using USB is that there's no guaranteed packet delivery time (which does exist for e.g. firewire), which is kinda important for audio streaming.
 
Regarding the link above..."oh bloody hell not this crap again"...
 
First thing I want to have a go at is this statement: "While this view has long been debunked".  Has it bollocks.  By whom, and when, where's the evidence?  Use your head; reject any and all unsupported claims.
 
There are two layers of Cyclic Redundancy Checks for all transmitted USB data; 5 bit for token packets and 16 bit for data packets.  If the CRC checks pass, you can be pretty damn sure the data has been successfully transmitted and received.  ACK and NAK handshaking and ERR reporting are all implemented.  How do I know this?  Because I've worked on USB driver stacks, some pretty horrible ones too (see below...)
 
If you have poor cabling yes you can have far too many retries, poor transmission rates, lousy bandwidth or even a complete lack of functionality.  Most if not all problems, imho, are caused by badly written USB drivers (man I've seen some that would make your eyes water and children cry), badly implemented electronics, out-of-spec components etc.  As long as the drivers are well written, the hardware has been well designed, the components and cabling are in good condition then it will work as expected.  It's science.  And logic.
 
If your driver is some broken-ass numpty-written pile of crap then ofc you are going to have problems.  I don't believe in space magic, nor do I believe in magical bit massaging hardware which corrects USB data transmission problems.