I used it in the iFi Isolator.
Yes. A lot of these improvements/changes depends on complex system level factors.
Interstage Isolation is just as valid.
For DIY and ease of use the latest generation of High Speed capable USB 2.0 isolators are IMHO the better choice.
But a lot depends on how hard/easy it is to import from a given source to a given destination. Small items from China to Thailand, super easy.
From outside, either expensive (use FedEx air freight, tax/duty prepaid with a hefty service fee) or unconvenient as the risk of customs impounding the item is high, debating the declared customs value and ***** new taxes, duty and you have to sort payment and how to get your item.
If it really get's bad, customs impound the FedEx shipment and demand documentation to prove value, then find that the customs class was wrong (which is debatable) ***** new duty/tax and then FedEx charges another service fee, on top all that customs take.
I used linear supplies for the USB circuitry.
Yes, EOL'ed forever.
All these isolators use some form of RF carrier (capacitive/inductive coupling) or piezoceramic.
The delay of the isolators is not constant (it varies at least one but often many cycles of the carrier) and substantial. Getting all the ducks on a row and to work together is non-trivial.
It's worse with a double trip sending the MCK clock upstream and the data downstream.
An option is to Gigabit LAN transformers to isolate clocks (use isolated LVDS) but it is not applicable to the data lines.
So we need a double flip flop with the input flip flop clocked on downstream BCK and the output clocked on our MCK.
But that set's up circulating currents anyway. Easier, solid ground plane, multiple power supplies.
This was the PSU of the digital section of the CD-77 (separate transformer for analog). It used a double-C-Core with small airgap, 400Hz rated core (thinner laminations), multiple shields, six windings, potted in mild steel magnetic shielding can.
Thor
Acording to CD Jitter by Paul Winser 1993.
Paul W. used 10131 dual D master-slave flip flop and 10213 triple deferential line receiver. With these markings produced by Signetics 😉 (same brand as the first pieces of TDA1540...)
The equivalents from Motorola are MC10131 and MC10213 parts.
These parts was used for clock management.
And They are from Digital ECL series.
Unfortunatley I think they are obsolete. I have some pieces from decades ago by Motorola...
.
Note that ECL logic are suplied from -5.2V power, So this could be the reason of existing -5V power at TDAs. As @ThorstenL also explained before.
.
page 8
"Appendix: ECL Circuits
Emitter Coupled Logic differs from the usual bipolar and CMOS technology of common digital logic. Traditionally used for very high speed systems, it is now serving only niche applications because of the rise in speed of CMOS devices. Unlike other logic families, ECL employs a low voltage swing of around 1V, driven by non-saturating transistors. Logic elements work by current steering rather than voltage switching. It is suitable for this design because the switching speed is not only high, but as the transistors do not saturate, there is no charge storage delay effect so the switching is precise and regular. Because it is single ended, ECL circuits require load resistors, and these need to be of low value to maintain switching speeds, so the power consumption is relatively high. Noise immunity is highest when signals are referenced to the positive supply, so that is generally grounded, and a negative supply of -5.2V provided."
.
Contemporary types are from the MC100EP series as @ThorstenL noted with other types. This series has single F-F packages, also Differential in-out types also single, that can be advantage for decoupling power supply separatly in each different F per Flip-Flop...
Classic representative from contemporary MC ECL series is single F-F MC100LVEL31
.
Also I found some diskrete translators from Philips aplication note and other sources that can be illustrative.
.
So basicaly we have 2 concepts of digital input management.
One with single ended input-outputs classic digital ICs
and other with SE to differential ECL translators following diff. F-F for recklocking.
.
I must said that even for short distances 5-10cm of differentiial Digital input signals, the sound was somehow better?
I dont know why maybe because zero crossing point relative?
(I used and listen with AM26LS31 / 32 4 x receiver - driver ICs. Not more than 10cm conn. with less termination "force" I think that was 1K load at termination diff. line... I was measuring with scope and this vaue if i can remeber was better than standard low value).
.
So I would do:
Digital isolation - diff level translator - 2 x diff. F-F recklocking - attenaution to the inputs
.
I will draw some schs...
It has capacitive coupling and magnetic coupling trough the TX1.
TX1 should be splited on 2 transformers. From the right 3 (or 4) secondaries one, and rest second.
In the "middle" point of digital isolation before dac. where is the blue line on the picture, shoud devide TX1 on 2 transformers with separate cores and primaries... These 3-4 PS branches should be from one transformer core and just for dac dedicated module.
Other suplies before dac unit and isolation is pure digital and PS should be originated from separate transformer.
I think that it wil be no back MCK because it is generating at the USB / I2S interface. And will be distributed only "downstream"?
Last edited:
Maybe not? Every recklocking is done by te MCK BCK line too.
Only IF we remove standard 22.x MHz from the USB board, replace them with small PCB with double Fo oscilators, divide by 2 and feed the USB board. Enable which one is used with SR 44.1/48KHz base is already present on the foot prnt of oscilators.
Then we can recklock with undivided F of oscilators, the BCK of 384KHz SR, because the MCK will be 2X higher and in phase with BCK for this SR 🙂
.
For the external DEM we can divide 8 times 2**8=256 times that is 8 F-F in serial or 4 ICs of double FF
For constant 176.4KHz external DEM coresponding with 12% of 1/2 LSB Iref with 1uF Cmsb.
.
I think that the Frequency of external dem and dem pins should be the same, and not changing with SR it should be constant
176.4KHz. But that deserves some measurements. I dont know...
That is incorrect. All standard streaming protocols via TCP/IP networking (and incidentally also USB & Firewire) use Isochronous transfer mode.
This means there is a guaranteed bandwidth, but not guaranteed data integrity. There is no re-transmission on error and all error checking / concealment etc. mechanisms are inherited from the "gold standard - perfect sound forever" source, that is CD Optical disk.
Relocking is NOT "asynchronous" operation, it the opposite, it is synchronous. Asynchronous sample rate conversion is also a separate process. Some streaming system deliberately operate in ASRC mode to resolve the many issues when attempting to operate in true asynchronous mode.
Asynchronous operation implies a local clock not phase or frequency linked, a buffer and a mechanism to keep the buffer fill level sufficient to support uninterrupted dataflow out, by making and receiving pull requests from the data source. Which is why isochronous mode is used.
There is a lot of misleading advertising and misunderstanding around all these issues.
No doubt, technically speaking this is a highly questionable statement.
If directly making a sample-by sample read from local hardware storage (SSD, SD Card) without an extra OS etc. we can be sure that the data is current (corrupted storage excluded) to that on the storage (which may or may or not be bit identical to the source), otherwise we cannot.
Thor
Each winding is individually screened from other windings, core, screen = earth. It is drawn actually, the individual screens.
Nope, it should not.
Then isolation is not recommended, as otherwise the MCK jitter is significantly increased, to a point where using this isolated MCK is pointless to use as reference clock for reclocking.
Using LVDS with Isolation for the MCK is possible:
Ideally a LVDS receiver directly to PECL, I guess...
But then again we have the issue with a lack of phase-link and needing to get the jittery BCK and DATA into the correct window.
So we need two blocks of latches - one running on BCK to latch the inputs correctly (CMOS is ok here) and a second set running on MCK (PECL here?).
Maybe just forgo this isolation and place the problem at the external connector?
Thor
I2S is not async. You are confusing USB with I2S. Most USB-I2S boards use USB in asynchronous mode but I2S is still synchronous.
I2S and/or SPDIF can be made in practice asynchronous using a sufficiently large elastic memory buffer and a suitable, low jitter programmable clock source.
In this case, the way I have implemented it previously in XMOS XU216, we set the clock to the nominal reported sample rate and start outputting data with the buffer at half full/empty.
In XMOS we can report accurate buffer fill, so we evaluate if the buffer is stable, growing or shrinking and then use micro-stepping of the clock to oppose the buffer filling up or emptying.
My implementation used a variable "lock" timing with the loop testing for "buffer growth/shrinkage" so that fast clock changes are tracked rapidly while with a stable clock the actual update rate goes into 10's to 100's of seconds with reset to fast mode by 1/4 or 3/4 fill level interrupts. The clock used is no longer available and offered 12Hz resolution at 1024X clock speed with "femtoclock" jitter levels (basically no worse than the better Crysteks) if given a sufficienty accurate 10MHz reference clock.
In practice both input and output clocks are completely asynchronous (not even frequency locked) and at the same time the output jitter is at "femto-clock" levels. Sadly after I left iFi/AMR never introduced the design into production, it was a DAC including 8 X BB/TI segment DAC IC's in four interleaved DAC Banks.
This Photo shows the MCK distribution to the 8 DAC IC's:
Thor
Did I said it was async, ? I am NOT confusing USB with I2S ! I haven't associated in my answer the I2S as an Async protocol. But talked about what happened in those USB receivers that have I2S outputs. They do have a clock with two crystals. I perfectly no what happen in the one shot transport protocol just before (PC ot spurce via USB, Tcp/ip). I adapted my answer to the asker I know the system and the confusion about that.
Last edited:
I just said there were errors and corrections when it is a CD optic reading. I don't talk about that for USB, TCP/IP! Do I say tcp/ip was a guaranted protocol ????
You also forget there are buffers when talking about isochronous and receivers. As far we talk about TCP/IP which is not the subject really in the question of the poster which I suspect the word streaming is also about a pc with USB feeding a DAC in his mind! It is streaming, while for some streaming is indeed just related to networks.
Is there no local clock on those USB to I2S boards ? Yes in all of them. It is not anymore the clock of the transmitter ! Hence asynchronous, no ? Then I didn't wrote I2S was asynch or whatever, I know it is not a diferential pair as USB ! I just write I2S (output of the board to the DAC) was a local short distance transmission protocol !
You guys made people say what they never said !
Margin of losses is exactly what describes the Red Book about optical reading the asker was talking about then mixed it somewhat with sampling rate and I2S word. I answered just the simplier way tio debug is question as I know he has a SDTRANS board . Good luck to find a bit missing between a SDcard or a HDD to the next buffer ! While with cd, we know there can be errors.
Last edited:
The System MCK, which also is divided to give BCK/SCK.
Incidentally, I2S over HDMI (e.g. PS Audio standard) do includes MCK. The Philips documentation includes nothing that forbids the additional transmission of a system clock.(aka MCK) with the other signals.
My implementation used only SCK from the HDMI input to clock samples into the buffer.
Thor
Correct.
But you were implying that they did not apply to other methods of transmitting audio, via network or USB etc.
As I had to immerse myself in these standards in detail, I was surprised to find that almost all use the same fundamental model as CD.
In modern data transmission lingo this is "isochronous mode" . It is used for AV streaming pretty much exclusively, including anything UPNP.
The reason roon refuses to support UPNP and related AV networking protocols is exactly that. They insist on R.A.T. only to avoid this data corruption.
A buffer cannot make up for data that arrives corrupted or, with TCP/IP arrives eventually, but after the time window in which it was needed to be streamed.
The beauty here is, it's all the same, with the same underlying system and the same problems.
All these streaming systems are isochronous (including USB Audio, FireWire, Thunderbolt etc.), all of them are vulnerable to data corruption, in which case the precise mitigation strategies as for CD are deployed.
That is why for example USB Cables can cause audible differences even if they only carry data and not power.
We have another round of "digital is not really that digital" and "inherently imperfect sound forever".
Thor
Thor, I was specifically talking about optical reading when errors applies more in my opinion than any others more modern numerical data stockage protocol. HDD have of course mechanical properties, SDD can also loose sectors. But I never lost any information in SAN farms, Geo clusters, or an hyper-V servers replicating live or from a saving.
I am sorry if my english isn't maybe rich enough to express what I thougth. With all those buffers everywhere, whatever the speeds, transmission works fine if you use the support which is rated for them. You always can lost blocks during transmission, nothing is perfect, but in reality whatever tera flops of datas, I never complained of any problems, and also with all those mechanicals things (tapes for instance). Btw it is certainly interressant to make an analogy with fiber and cd disc because of the use of ligth.
There is a power line in USB as you know, whatever it is shielded and the two transmision line too, it stays the electro magnetism domain and there is that ref wire too that has is rock'n roll life style and its cladestines!
There is no digital as there is no ground, as far i know all those electricity flows an analog way, at least its support is very not digital. So there is no doubt datas are power ! 🙂 (I mean it is electricity)
I don't said the buffers can invent anything, it is made good enough for you do not complain of any loss vis a vis what enter at their door. We know the distance, the arcs for the physical networks whatever copper or fibers when it goes not straigth in a street, a building, etc. for our buffer at each nodes receive what what sent before and make their job and we repeat the transmission as you know. I mean losses are marginals.
Sorry if there is confusion in my words. I think Async refers about that pcb to the fact there is a clock on which refers the output transmission ! And here you can object it can not make up anything too if datas were lost before ! Correct ! I hope we have not lost sumotan, maybe because my english someone else should answer his question for clearer. I can understand the way it was answered one can think the I2S line is asynchronous. I do not think most of users enter that deep in the attributes of what happen before on the USB link then after on the I2S, I am sure of that knowing the asker. That's all I wanted to say. Maybe I should have said Async means it is not direct timing from the source. But I'm sure one found something to say "no because". Let say I tried to be didactic 😉
for answering @sumotan question I buffer it here : "
OT question if I may, yes Im aware the music streaming is the way to go now. Putting aside up sampling etc, sound wise
how does it compare to good old transport fed via direct I2S to the TDA, yes its just Red Book playback but ????"
After all we have yet people thinking a fan into a pc is a problem for HDDs ! (all that ventilated packets 😉 ) !
I remember John finished by using USB sticks and USB cards, but it certainly was because of noise and certainly not loss of datas ! You have more chance to loose a packet in a Boeing than from your HDD on your local network !
I am sorry if my english isn't maybe rich enough to express what I thougth. With all those buffers everywhere, whatever the speeds, transmission works fine if you use the support which is rated for them. You always can lost blocks during transmission, nothing is perfect, but in reality whatever tera flops of datas, I never complained of any problems, and also with all those mechanicals things (tapes for instance). Btw it is certainly interressant to make an analogy with fiber and cd disc because of the use of ligth.
There is a power line in USB as you know, whatever it is shielded and the two transmision line too, it stays the electro magnetism domain and there is that ref wire too that has is rock'n roll life style and its cladestines!
There is no digital as there is no ground, as far i know all those electricity flows an analog way, at least its support is very not digital. So there is no doubt datas are power ! 🙂 (I mean it is electricity)
I don't said the buffers can invent anything, it is made good enough for you do not complain of any loss vis a vis what enter at their door. We know the distance, the arcs for the physical networks whatever copper or fibers when it goes not straigth in a street, a building, etc. for our buffer at each nodes receive what what sent before and make their job and we repeat the transmission as you know. I mean losses are marginals.
Sorry if there is confusion in my words. I think Async refers about that pcb to the fact there is a clock on which refers the output transmission ! And here you can object it can not make up anything too if datas were lost before ! Correct ! I hope we have not lost sumotan, maybe because my english someone else should answer his question for clearer. I can understand the way it was answered one can think the I2S line is asynchronous. I do not think most of users enter that deep in the attributes of what happen before on the USB link then after on the I2S, I am sure of that knowing the asker. That's all I wanted to say. Maybe I should have said Async means it is not direct timing from the source. But I'm sure one found something to say "no because". Let say I tried to be didactic 😉
for answering @sumotan question I buffer it here : "
OT question if I may, yes Im aware the music streaming is the way to go now. Putting aside up sampling etc, sound wise
how does it compare to good old transport fed via direct I2S to the TDA, yes its just Red Book playback but ????"
After all we have yet people thinking a fan into a pc is a problem for HDDs ! (all that ventilated packets 😉 ) !
I remember John finished by using USB sticks and USB cards, but it certainly was because of noise and certainly not loss of datas ! You have more chance to loose a packet in a Boeing than from your HDD on your local network !
Last edited:
So in essence you are micro-stepping SCK. Hard to see this would be an improvement over ASRC or FIFO with SPDIF. Useless with async UAC2.
If you so want. Internal SCK.
ASRC are not data transparent and most implemented audio ASRC can be shown to encode input clock jitter into the audio data.
If the levels of this is material is another question, but if using multibit PCM DAC's without oversampling all this is conceptually undesirable.
FIFO without clock management must show buffer under/overflow with sufficient time.
If the buffer is too long any Lip-Sync of audio is impossible in AV use. My own system is always A / AV (and 2 channel) so I account for that sort of thing.
So we are usually limited to 100mS or so of delay and thus a 200mS buffer.
The "elastic memory buffer" is actually of course a FIFO, the key is to manage the clock synthesis IC based on the buffer fill state that is critical as difference and the fact that's it's just part of the XU216 without external hardware other than the I2C controlled clock.
Actually I used the same buffer as used in the XMOS and much of the logic that maintains the UAC2 async system, with a fixed clock.
In effect I changed the effector logic after the various blocks to control the clock for the output, instead of issuing pull requests to the source.
Most of the resources and dataflow are the same for USB, I2S (external LVDS on HDMI) and SPDIF. The principle is actually extfnsible to any form of data source.
Most of the OTS network streaming solutions I evaluated cannot work as I2S slave, with clocks from the hosts and their own clocks are extremely poor. External.clocking means ASRC kicks in.
Being able to take highly jittery but bitaccurate I2S from wireless and network audio modules (including Dante) was one of the reasons for development of this.
Thor
Last edited:
Thanks for the indepth explanation Iggy, aah yes I forgot that my TransSD can be configured to play hi res files etc Lol.
Still me thinks direct I2S at least for the TDA still has its advantage over streaming be reclocked or not.
For me be it commercial or whatever reasons, I always feel that Red Book has never been fully capitalized hence even
now @thorsten has discovered more to up the performance of the 1541.
Cheers
Still me thinks direct I2S at least for the TDA still has its advantage over streaming be reclocked or not.
For me be it commercial or whatever reasons, I always feel that Red Book has never been fully capitalized hence even
now @thorsten has discovered more to up the performance of the 1541.
Cheers
What do you mean?
t is not possible to isoilate only GND - "hot signals" (D+,D-) cannot work without GND
Only 5V Vbus not required, if the external PS used.
So, or it is isolated, or it is not isolated.
USB Isolators (like TI, AD and other) - isoilates all.
To supply 5V to a device connected through an isolator, DC-DC or external power source should be used.
?!
74HC, HCT, AC, ACT, LVC, ect - all are cmos and smd of course.
(who need non smd now ?!)
. . . Off Topic . . .
Please gentleman get back to the topic.
Update:
I have tried to contact someone here who appears to have a lot of documentation on Philips products.
Hopefully something shows up.
Please gentleman get back to the topic.
Update:
I have tried to contact someone here who appears to have a lot of documentation on Philips products.
Hopefully something shows up.
Last edited:
Bit-perfectness is necessary in verifying digital communication but hardly needed in practice for audio. With digital volume control, resampling, format conversion etc. bit-perfectness goes out with the bathwater. To avoid intersample overs lowering the digital volume by 3-6dB (and thus losing bit-perfectness) is the easiest mitigation.
I agree. Although some FIFO mongers claim to mitigate this by reseting buffers when stream has data silence. I have my doubts about that scheme.