Computer Audio Asylum

Music servers and other computer based digital audio technologies.

Return to Computer Audio Asylum


Message Sort: Post Order or Asylum Reverse Threaded

Yellowtec PUC2

213.89.140.239

Posted on June 15, 2010 at 16:19:46
struts
Audiophile

Posts: 15
Joined: April 14, 2010

The Yellowtec PUC2 'Professional USB Audio Interface' has been stirring up quite a lot of dust over here recently. Information on the website is scant, does anyone know anything about this unit? In particular does it use Asynchronous or Adaptive mode USB? Has anybody compared it to a consumer unit like the Ayre QB-9?

 

Hide full thread outline!
    ...
RE: Yellowtec PUC2, posted on June 16, 2010 at 06:19:33
Gordon Rankin
Manufacturer

Posts: 2947
Joined: June 9, 2000
Struts,

I am just guessing here... but I would imagine this is a design based from Ploytec as Markus and I talk allot about this kind of stuff and he is the designer for most of the Yellowtec products(at least the USB side of the equation). Basically this would be based on their block mode drivers for Windows and MAC. It would use the Atmel AVR32 UC3A3 processor and would be capable of 24/192 output.

Otherwise I have no idea how well it works. It would be really tough to do AES correctly considering the power required at 192K to be powered from the USB only.

Thanks
Gordon
J. Gordon Rankin

 

RE: Yellowtec PUC2, posted on June 16, 2010 at 12:15:43
struts
Audiophile

Posts: 15
Joined: April 14, 2010
Thanks Gordon, from this I take it that Yellowtec is not a Streamlength licensee!

You're right about Ploytec, this is confirmed by the screenshots of the firmware updater on the Yellowtec website. However someone on one of the local Swedish boards claims it is an Aynchronous implementation, I don't know where they got that information.

I can't find anything about the actual chipsets used (the same source claims the DAC is a Cirrus CS4272) however I have no idea which USB receiver chip it uses. The AVR32 UC3A3 datasheet only mentions a 'Hi speed USB OTG' which is not very helpful. I assume the OTG functionality is not being used in this implementation.

Folks here are reporting very good SQ out of this unit with no mention of any dropouts, although afaik nobody has tested with any 24/192 programme yet.

Hopefully someone will open one up soon and post photos so we can see what it is really made of.

Thanks again.

 

RE: Yellowtec PUC2, posted on June 16, 2010 at 17:30:12
Charles Hansen
Manufacturer

Posts: 6984
Joined: August 1, 2001
>> one of the local Swedish boards claims it is an Aynchronous implementation <<

It may in fact be. Gordon's previous post mis-typed "block mode" instead of "bulk mode". Bulk mode is the way the computer communicates with something like a hard drive. It is not given priority like an isochronous device, which is designed to carry sound without interruptions. (Isochronous has two sub-divisions: adaptive, which has higher jitter and asynchronous, which has no jitter in the link.) Bulk mode requires that custom device drivers be installed. Depending on the device drivers and the DAC itself, bulk mode can be either asynchronous or adaptive.

I believe that Ploytec has written some asynchronous Windows drivers, so this device may well be asynchronous. And bulk mode normally doesn't cause problems unless you are really stressing the system. As to how the thing sounds, I cannot help you there.

 

RE: Yellowtec PUC2, posted on June 17, 2010 at 01:27:19
struts
Audiophile

Posts: 15
Joined: April 14, 2010
Thanks Charles. You mention that "Depending on the device drivers and the DAC itself, bulk mode can be either asynchronous or adaptive" however reading the USB spec I couldn't find any mention of asynchronous or adaptive bulk mode transfers and I can't really see how the concepts apply here. Bulk mode seems to me to be analagous to moving water around in buckets as opposed to pipes, so 'flow control' is kind of irrelevant. Could you please point me in the direction of anything that explains this in more detail?

 

RE: Yellowtec PUC2, posted on June 17, 2010 at 13:43:26
John Swenson
Audiophile

Posts: 2422
Location: No. California
Joined: October 13, 2002
Bulk transfers still have flow control. The host does not send more data until the device informs the host it has successfully received the data. Thus it is in essence asynchronous. A clock comming from the DAC can be used to clock the data out of a buffer and the level of "fullness" of that buffer can be used to control how fast data gets put into the buffer. There are two ways to do this. You can invent your own protocol and define explicit stop and start messages the device can send to the host which get interpreted in your own driver, or you can just not send the "received data successfully" message when the buffer is getting full. Either way works.

With Bulk mode you just can't guarantee that there will be enough bandwidth to support it, but with modern systems that is usually not a problem.

John S.

 

Thanks, John., posted on June 17, 2010 at 18:48:50
Charles Hansen
Manufacturer

Posts: 6984
Joined: August 1, 2001
You know far more about computers than I do. I know just enough to get into trouble...

 

RE: Yellowtec PUC2, posted on June 18, 2010 at 02:25:59
struts
Audiophile

Posts: 15
Joined: April 14, 2010
V. interesting, thanks. So if that's the bulk mode equivalent of asynchronous what does the bulk mode equivalent of adaptive look like?

 

RE: Yellowtec PUC2, posted on June 18, 2010 at 12:58:36
John Swenson
Audiophile

Posts: 2422
Location: No. California
Joined: October 13, 2002
I don't think there is such a thing. Bulk mode is always a two way protocol, the host sends data and waits for acknowledgment from the device. A bulk mode transfer cannot just shove data down the wire.

By its very definition the concept of an adaptive bulk doesn't make sense. Isochrononous transfers send data at a specific transfer rate, so many bytes per second, bulk just sends data with no timing whatsoever implied. How can the device "adapt" to that?

Audio with bulk works because there IS flow control with bulk mode. The host starts sending data as fast as it can until the device buffer gets almost full, the device tells the host to stop sending data, when the buffer is getting empty the device tells the hosts to start sending again. The hosts then shoves a bunch of data at the device as fast as it can etc. The device is always in control of the overall transfer rate, hence it is inherently an "asynchronous" interface.

John S.

 

RE: Yellowtec PUC2, posted on June 18, 2010 at 13:35:49
struts
Audiophile

Posts: 15
Joined: April 14, 2010
Makes perefct sense John, thanks. I think I was taking Charles' earlier response a bit too literally.

 

Clarification, posted on June 21, 2010 at 11:06:09
Charles Hansen
Manufacturer

Posts: 6984
Joined: August 1, 2001
I did some more research to follow on my poor memory regarding adaptive mode on FireWire. As John Swenson said, all bulk mode transfers must be asynchronous. However, FireWire does allow for an adaptive mode. It is part of the isochronous mode, which means that the signal flow is continuous.

In this mode there are two signal wires, called "data" and "strobe". When these two signals are run through an XOR gate, they produce a (relatively) steady clock signal. The FireWire spec reserves 80% of the bandwidth for isochronous and 20% for bulk mode.

I would say that isochronous FireWire would have lower jitter than an equivalant S/PDIF connection, but not as low as asynchronous (USB or FireWire). The thing that I have no idea of is how many FireWire devices use isochronous and how many use bulk.

Hope this helps...

 

And more information, posted on June 21, 2010 at 20:04:52
Charles Hansen
Manufacturer

Posts: 6984
Joined: August 1, 2001
Gordon pointed out that the existing FireWire chipsets used for isochronous (adaptive) mode have horrible jitter. Something like 10x worse than a good S/PDIF connection. And in my view, S/PDIF is fundamentally flawed.

So I would say that unless your FireWire equipment is using Bulk (asynchronous) mode, that you are probably better off with some other type of computer audio device.

 

RE: Yellowtec PUC2, posted on June 27, 2010 at 02:36:57
struts
Audiophile

Posts: 15
Joined: April 14, 2010
Thanks all for the responses. I have now had it confirmed that the PUC2 uses iso async mode, although of course it is not plug-n-play at Fs > 48kHz like the Streamlength implementation.

Regarding power consumption at higher sampling rates I note that the CS4272 alone typically draws 433 mW, max 510 mW (in addition to whatever power consuming/dissipating circuitry the PUC2 contains), pushing it as Gordon speculated beyond the limit of a 'low power' USB device. This means it will not be able to work (at least in whatever mode(s) correspond to this 'max' condiiton) with USB hubs which don't offer 'high power' receptacles.

Trying to get someone who has one to send me a picture of the circuit board so we can get a better idea what's going on in there.

 

RE: Yellowtec PUC2, posted on January 19, 2013 at 15:46:23
erin
Audiophile

Posts: 31
Joined: May 29, 2010
Old thread but anyway... I looked inside a Yellowtec PUC 2. It has many chips inside it. One seems to be a microprocessor, or FPGA. It has two boards, but I did not remove the top board to check the exact part number.
It seems very well engineered.

Using it to feed my DAC with the AES output - compared it back to back against An Audiophilleo 1.

Both sound very good. But the Yellowtec PUC 2 is the winner.
Audiophilleo, gives a slightly more recessed sounding midrange and softer highs. Both are very good, but for around the same money the Yellowtec PUC 2 gives even more overall clarity and depth of sound than the Audiophilleo 1.


 

RE: Yellowtec PUC2, posted on January 19, 2013 at 17:50:47
erin
Audiophile

Posts: 31
Joined: May 29, 2010
Yellowtec PUC 2 review

 

Page processed in 0.021 seconds.