|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
125.167.101.185
In Reply to: RE: async & cMP2 posted by play-mate on March 12, 2012 at 03:25:07
WaveI/O card uses ASIO...
As it output I2S I would be interested to know which DAC you connected it to.
Follow Ups:
Bibo01,
My Dac is a DIY TDA1541a based DAC with a 6n2p tube output stage. I started with the audio board from an Arcam Alpha CDP. There is not much left from Arcam but the box. Power supply is all BG and Oscons with Burson regs. Tubes have choke supply on B+. DEM reclocking per Grundig design. Separate Plitron transformers for DAC and tubes. I use mBNC connectors for the I2S signal. Not perfect, but seems to pair well with WaveIO.
Dear Bibo01
hmmmm....see, ASIO is a software protocol, and I2S is not a protocol at all, ey ?
One can start wondering why cics implemented tiny, small, medium & large communication buffers, and drew so much attention to buffersizes, as in theory, when it comes to pure playback, long buffers should be as good as small ones.....
I´m not really convinced that just because USB is async and derives its clocking from the DAC, that everything is as straightforward simple as that....
I always come to think of how much difference a new Lynx WDM driver can improve sound quality and how much time & effort cics put into cPlay´s ASIO/DSP optimization.....
I seriously believe that driver software is the most underestimated part of any digital enginering and that it is too easy just claim that async is the blessing of the holy grail.
kind regards
cMP2 Computer w/digital crossovers & FIR filters > Lynx Aurora 8 FireWire /192kHz all channels. 2x AcousticReality Ref. 202 & 2x AcousticReality Ref. 601´s ICEpower. Magnepan MG3.3R beechwood frames & custom stands. Miller chokes
ASIO is a software protocol and I2S is not a protocol at all, ey ?Correct. ASIO is a soundcard driver protocol; I2S is an interface standard, not a protocol.
The Thesycon drivers used by the Wave I/O device and other USB-based ASIO drivers (e.g. the Ploytek/AQVOX driver) bypass the Windows USB Audio drivers to transfer data straight to a device (using the PCM270x, that XMOS something-or-other or the TAS 1020) which in turn pass the data over the I2S bus to the DAC. They do so asynchronously (Thesycon) or (if I have the term right) adaptively (Ploytek).
This ground has been covered before - see link and the replies, esp, as ever, the one from John Swenson.
I seriously believe that driver software is the most underestimated part of any digital enginering
I'm sure you're right but reports are that the Thesycon drivers used for Wave I-O device are particularly robust. IIRC, Thesyon supplies drivers for some of the much-respected Ayre products. Its people do know what they're doing.
it is too easy just claim that async is the blessing of the holy grail.
Also correct only I'm not sure that anyone does claim it's a Holy Grail. Again, reports have it that the protocols work well in many implementations - including cMP^2/cPlay. If you take a few moments to visit the thread wlowes linked to, you'll see that a number of cMP2 users are already successfully using the Wave I/O device.
. . . the protocol you´re running is the "weak" point, and could possibly gain even more quality if it could run ASIO.
It doesn't "run" ASIO, it conforms to the ASIO standard.
Edits: 03/12/12
Hi Dave,
Pardon me, but I did read the two links you´re refering to, but I´m still not convinced that it´s irrelevant how cPlay connects to the DAC.
It´s however not a question of that an async USB DAC can work with cPlay, but rather how.....
Apart that I´m very sceptical to how well all these newish async DACs actually "eliminate" the (jitter-) influence from the computer.
The theoretical thesis is that when cPlay (i.e. the PC) is slaved to the DACs masterclock, jitter becomes irrelevant, right ?
So how can wlowes experience a difference then ?
-is it only ground-noise that makes the difference ?
According to cics (and many others) it is jitter that alters soundquality (bit-perfect transfer granted), so it does not make sense that there should be any perceptible SQ difference.
When I first switched from internal Lynx Two-B (fully optimized cMP2)to external Lynx Aurora via isochronous FireWire, I was somewhat surprised that switching from cMP2 to regular XP, did hardly make any difference at all....I did expect at least a little.
Second, I´ve witnessed several software upgrades on the Lynx drivers and a lot of us have marvelled about cics work on cPlay´s DSP and ASIO software.....
My point is that software is an essential part of a devices performance and most manufacturers have a very "casual" attitude to this.....
Surely, it´s cheaper, easier, faster and less complicated to licence al sorts of "asynchronous USB" circuits and advertize it as "immune to jitter".....
Infact I have the impression that manufacurers just pick´n mix design features from a catalogue. And where this is perfectly acceptable in order to implement well-enginered technology at a price-point, I feel it´s problematic to claim that only because it´s "async" it eliminates all jitter issues.
-it seems that there are ways of "async" that do not capture the benefits entirely....
kind regards
cMP2 Computer w/digital crossovers & FIR filters > Lynx Aurora 8 FireWire /192kHz all channels. 2x AcousticReality Ref. 202 & 2x AcousticReality Ref. 601´s ICEpower. Magnepan MG3.3R beechwood frames & custom stands. Miller chokes
Post a Followup:
FAQ |
Post a Message! |
Forgot Password? |
|
||||||||||||||
|
This post is made possible by the generous support of people like you and our sponsors: