Phasure NOS1 vs. Pacific Microsonics Model Two

[1audio]

I'm curious which ESI card and driver supports this sample rate? I checked and the only current pro cards that goe above 96 seem to be the Juli@ and the Maxio. The control panel for those stop at 192.

 

I think the idea of packaging the card and the dacs in a separate box is a very good one. I'm not enthusiastic about PCI express because its a serial interface with a serdes at each end and a not too synchronous communications unlike PCI, but its much faster so that may not affect things as much. Also PCI may well be obsoleted in the not too distant future so we may all be migrating.

 

[1audio]

When used with a Lynx, RME or Mykerinos card using external word clock from the Model 2 the system is effectively asynchronous, since the master clock is inside the Model 2 and the upstream chain is locked to the Model 2. This is clumsy since every sample rate change requires manual intervention at the Model 2 but it does a good job. None of this addresses the effects of RF leakage and conducted emi in the cables between the boxes. Keith Johnson spends considerable time checking for problems when he sets up the Model 2's and he uses isolation transformers on the power to reduce these effects.

 

 

 

[1audio]

"And to address Demian's point of a clock linked PM-2 being asynchronous at the same time, yes I agree, to a point. The PM Model still uses SPDIF, and this requires the attendent SPDIF receiver, which I believe it is correct to say, will still add (some) jitter even in a clock linked scenario. (Not to mention the accumulated jitter caused by the clock linking itself, cable losses/reflections, signal transmitter losses, etc.)-inherently, a system using a single fixed frequency clock, adjacent to the DAC chip(s), without having to send that clock anywhere else is ultimately going to result in the lowest possible jitter-assuming equal implementation."

 

It the PM Model 2 there is a dual crystal oscillator located very close to the DAC's. It runs at the "master clock" frequency. It is divided down to the bit clock and to the word clock frequency, a process that reduces the phase noise, the jitter remains constant. The external data source when locked to the word clock should have essentially no effect on the clock if the isolation is good. The key issue becomes eye pattern and data accuracy which is essentially perfect in this scenario. The data stream is driven by the clock next to the DAC, which is again ideal. (The PM uses AES dual wire for 192, not SPDIF. This is because when it was designed there were no 192/176 capable receiver chips.) This is in effect similar to what the NOS1 is doing.

 

Different DAC architectures are more sensitive to jitter at different clock inputs. Its not obvious from the outside which is more important without a good understanding of the guts. An early R/2R ladder DAC with a sample and hold on the output would be most sensitive to the word clock, since that drive the S/H. A Delta Sigma DAC is usually most sensitive to the master clock but not always.

 

Word clock became popular for locking different Digital Audio systems together because it would keep the data aligned pretty precisely and distribution is less sensitive to cable mismatches that bit clock or "superclock" (256X wordclock).

 

 

 

[1audio]

"It the PM Model 2 there is a dual crystal oscillator located very close to the DAC's.

 

It is allright to have oscillators in there, but they (IMO !) will be there for reclocking purposes only. Or some anynchronous SRC."

 

Reclocking can mean many things. In the model 2 the oscillators are used to drive the DAC's. When used as a master they are free running with no outside influence. When used as a slave they are phase locked to the external clock source, either from word clock in or from the AES stream. The PLL takes a long time to lock (as much as 10 seconds in some cases). This is typical of a high accuracy low jitter PLL. However in this case the clocks are running as Master.

 

"The data stream is driven by the clock next to the DAC, which is again ideal. (The PM uses AES dual wire for 192, not SPDIF.

 

Functionally speaking, AES will be SPDIF allright. Now, I really don't see how the data stream can be driven by oscillators in the DAC, while at the other end some oscillator(s) will be running, and *them* obtaining the data really;

If the connection would be async FireWire, yes, then I could understand.

but

Although I don't read it as such (and it will need the context of earlier posts I guess), when looked at this some other way around I don't see much what is wrong with your outlay. So, when the clock of the PM2 is connected to the original source, and *in there* the clock virtually is replaced by the one(s) in the PM2, yes. But only for theory and up to some degree, because it again (see my earlier post) depends completely on the architecture of this other source, and obviously this architecture is not under control of the PM2. So YMMV - it is nothing to depend on - users can not even check the real merits except for listening."

 

When a typical pro sound interface (Lynx, RME, Mykineros or even Juli@) is used with external clock or sync the internal clocking is locked to the external source usually with a PLL. In this mode the jitter of the data stream gets removed when the data is clocked (reclocked??) into the DAC. As long as the timing meets the requirements (set in the AES3 spec) the data will be accurate and the clock becomes that of the dac. Since the DAC is the master the buildup of Jitter in the soundcard gets removed as the data is clocked into the DAC.

 

"It is divided down to the bit clock and to the word clock frequency, a process that reduces the phase noise, the jitter remains constant.

 

This may come across as nit picking, but if it were for me, then each division of the clock will result in additional jitter. Something like 6dB.

About the reduction of Phase Noise I can agree I think. But this will be merely because of the specs of the oscillator which are unavoidable for its frequency, while not using that frequency in practice (but a division of it).

I can easily be proven wrong here though."

 

(Caution, Geek Speak ahead)This can be confusing since it depends on how jitter is defined in the context. If the Jitter is in absolute (RMS pS) then the jitter is constant (especially with a synchronous divider) with a very small penalty from the gates used. If specified in UI (unit interval) is actually is reduced as a function of the interval since its pretty constant and the interval is increased. The phase noise is reduced by 6 dB with every division for the same reason. Multiplication to higher frequencies has the reverse effect, leading to some curiosity as to how a word clock source can provide lower jitter than the internal clock. Perhaps good PLL's in those cases where it works? Or really poor clocks to start with?

 

Crystal oscillators tend to have the lowest noise at 5 MHz, increasing as the frequency goes up or down. The ultra low noise oscillators are very expensive. There is also a question as to when do the limits of the DAC prevent an improvement from improved oscillator performance. (FWIW, there are no 24 bit accurate audio dacs. There are a few slow 24 bit dacs but they are not useful for audio. A 32 bit dac is pure marketing, as the designer of one explained to me, thermal noise will prevent any meaningful output at bit depths much less than 32 bits.)

 

 

 

 

[1audio]

Keith uses a Lynx card on a Mac running Soundblade, or a Mykerinos card on a PC running Pyramix or a Lynx on a PC running Media Monkey with a BADA DAC depending. . .

 

He doesn't use any of the above for recording.

 

[1audio]

Its a tape system whose identity escapes me. I'll see if I can find out. They are busy right now, KOJ just won a Grammy for his surround recording of the Britten and they just returned from a successful recording project in Charlotte NC.

 

I would be very reluctant to poke around inside of a Model 2. There are interactions between the line receiver and the rest of the system that might get confused if the receiver is bypassed. The challenge of connecting to it is the dual link requirement. I have been looking at making an interface from the Juli@ to a dual link interface for the Model 2 and its clones. I may have a way finally but need the motivation to actually build them. With less than 100 or so of the model 2 in existence and more than a few in service where the interface isn't needed its a small market. Since this is more hobby than income for me it needs to be fun.

 

[1audio]

I hope to have a demo board in a few days that will give the clues to this solution. If it looks like it will work I'll pass along how to do it. If Peter is up to tweaking one and hooking it up to your box (in place of his DAC) that would be the best way to see how they compare. If after all of this his DAC is on a par (what I would expect at least) he will have accomplished quite a lot.

 

I still don't understand how Peter squeezes 384/32 through an I2S port that stops at 24/192 but then he is a magician.

 

[1audio]

I see those roadmaps but the Juli@ has one I2S port and one SPDIF port and the driver currently sends the same data to both, with the option to switch off one of them. Other versions of cards with the same ICE1724 chip can do much more but all of those skip the 176.4 KHz sample rate. However there is the potential of grabbing pins on the chip and customizing the driver opening many possibilities. However it may be less work to do that with a USB interface designed from the ground up.

 

[1audio]

Pretty extensive and details specs with very good measurements. Peter has done an exceptional job of addressing the challenge. I think the power line noise numbers should be in microvolts, not millivolts.

 

This also shows how good the Juli@ card is and how flexible it is.

 

TI has not come through with the demo board yet for the dual link experiment. I am expecting them next week or the week after. When I have it and have made sure it can work I'll try to work out the details and post them somewhere. The Dual link thing has had me vexed for a few years. KOJ explained that it was created because there was no 4X recording hardware so they had to invent it. And they would not have if there was the standard we use today. I have found no documentation on it and it seems to be a hack, but TI has support for it in their digital output chips.

 

I'll look around for a receiver solution from TI so we can get the output of a Model 2 into a Juli@ card.