Could you please tell me to which type of shunt implementations are you referring to? ... or which PSU you consider it would be appropriate for this task?
I'm in process of designing such an application and, for now, I'm stuck in finding a valid source for on-board oscillators. So far, I've tried NDKs but without success (unless I'll buy 1k units) and I'm looking to IQD... my next alternative. It seems that it's hard to find good crystal-based oscillators in Europe at a fair price. Crystek is an alternative but Mouser don't offer 22.5792 MHz parts in small Q (up to 100 pcs.); they hunts me down with 360 pcs minimum / order
Any help from you guys will be very appreciated!
L
Last edited:
I am
not an ee, and I cannot design the circuits in question. I was listing my requirements for such a device. For oscillators, is there a Crystek distributor in the EU? Perhaps you could obtain samples? Hear in the US parts can be gotten from Mouser. Maybe not cheap, but I believe there is Tent Labs in Europe, and they distribute high precision XOs. I suggested on board ps regulation, because such regulation needs to be close to the clock to be effective. I still believe that that the raw power from the USB bus can be used, as long as the requirements are around 300 mA or less, and a combination of filtering and regulating the supply is used to reduce the noise from the computer (Ayre successfully utilizes USB power).
If one was designing a module to be sold as a diy board to add to DACs, it would seem to be relatively simple to power it from the USB bus, and to have pads with jumpers on the board to allow the end user to add a dedicated ps if they wanted to.
not an ee, and I cannot design the circuits in question. I was listing my requirements for such a device. For oscillators, is there a Crystek distributor in the EU? Perhaps you could obtain samples? Hear in the US parts can be gotten from Mouser. Maybe not cheap, but I believe there is Tent Labs in Europe, and they distribute high precision XOs. I suggested on board ps regulation, because such regulation needs to be close to the clock to be effective. I still believe that that the raw power from the USB bus can be used, as long as the requirements are around 300 mA or less, and a combination of filtering and regulating the supply is used to reduce the noise from the computer (Ayre successfully utilizes USB power).
If one was designing a module to be sold as a diy board to add to DACs, it would seem to be relatively simple to power it from the USB bus, and to have pads with jumpers on the board to allow the end user to add a dedicated ps if they wanted to.
I've used Analog Devices adum34xx digital isolators between Cypress fx2 USB uC (usb powered) and the ADC data collection SciLab uC (external ps)
likely the USB ULPI byte wide phy interface could be isolated the same way
the hardware effort was relatively low compared to the ~2 man-years of programming time the project has soaked up for drivers and instrument UI and data acquisition/control code spread across 3 processors (PC, Cypress USB controller and SciLab instrument data acquisition controller)
this only works if there is a external digital bus between system parts the only solution for single chips would be serial audio stream digital isolation
the I2C could be isolated with the adum devices but they would introduce some jitter - maybe not a problem with ess Sabre DAC or similar jitter reduction in the audio DAC path
some claim sub nS jitter isolation is practical - http://www.nve.com/Downloads/ab17.pdf claims 30pS jitter
likely the USB ULPI byte wide phy interface could be isolated the same way
the hardware effort was relatively low compared to the ~2 man-years of programming time the project has soaked up for drivers and instrument UI and data acquisition/control code spread across 3 processors (PC, Cypress USB controller and SciLab instrument data acquisition controller)
this only works if there is a external digital bus between system parts the only solution for single chips would be serial audio stream digital isolation
the I2C could be isolated with the adum devices but they would introduce some jitter - maybe not a problem with ess Sabre DAC or similar jitter reduction in the audio DAC path
some claim sub nS jitter isolation is practical - http://www.nve.com/Downloads/ab17.pdf claims 30pS jitter
maybe I
am confused, so experts please correct me if I am wrong:
If one chooses to isolate the incoming USB data, jitter (at that point) should not matter, all that matters is having sufficient bandwidth to transmit the data:
Asynchronous transfer is managed by code, that prompts the computer when to send data, in order to keep the on chip buffer from over or under running its output. The XO(s) are only relevant on the output of the USB receiver, as long as one uses fixed high precision XO(s) at the output of the receiver, the jitter at that point will be as low as is allowed by the XO. The control code manages the buffer, and assures data in the buffer keeps "in time" with the output.
So there should be no additional jitter caused by the isolation scheme, the isolators just have to have sufficient bandwidth to transfer the data.
am confused, so experts please correct me if I am wrong:
If one chooses to isolate the incoming USB data, jitter (at that point) should not matter, all that matters is having sufficient bandwidth to transmit the data:
Asynchronous transfer is managed by code, that prompts the computer when to send data, in order to keep the on chip buffer from over or under running its output. The XO(s) are only relevant on the output of the USB receiver, as long as one uses fixed high precision XO(s) at the output of the receiver, the jitter at that point will be as low as is allowed by the XO. The control code manages the buffer, and assures data in the buffer keeps "in time" with the output.
So there should be no additional jitter caused by the isolation scheme, the isolators just have to have sufficient bandwidth to transfer the data.
sure, if the isolation is between the usb and the digital audio output hardware
currently there are no isolation chips for high speed 480 Mbuad usb signals
In the I2S isolation case the isolator would be after you have properly clocked the audio data stream for the DAC and so could add jitter
currently there are no isolation chips for high speed 480 Mbuad usb signals
In the I2S isolation case the isolator would be after you have properly clocked the audio data stream for the DAC and so could add jitter
Could you please tell me to which type of shunt implementations are you referring to? ... or which PSU you consider it would be appropriate for this task?
I'm in process of designing such an application and, for now, I'm stuck in finding a valid source for on-board oscillators. So far, I've tried NDKs but without success (unless I'll buy 1k units) and I'm looking to IQD... my next alternative. It seems that it's hard to find good crystal-based oscillators in Europe at a fair price. Crystek is an alternative but Mouser don't offer 22.5792 MHz parts in small Q (up to 100 pcs.); they hunts me down with 360 pcs minimum / order
Any help from you guys will be very appreciated!
L
Commercial mode on: see my website
Take a look at this Rigisystems Interface.
Supported audio sample rates: 32KHz - 192KHz
Externer audio clock inputFirst class locas clock generator
Separate Clock Domain for digital input S/PDIF
S/PDIF optical/electrical, autosignal and frequency detection
USB 2.0 high speed 480mbps
24b Audio
16 x 16 channelKanal audio @ 96KHz
additional 2 x 2 channels for digital S/PDIF audio @ 96KHz
8 x 8 channels audio @ 192KHzTransparent 32bit S/PDIF out
DSD Format, support for USBDSD
ASIO round-trip latency less than 6.0ms
Microsoft Windows 7, Vista, XP support
Apple OS X supportASIO 2.1 and WDM support
Windows and OS X control panel
Inclusing complete channel mixer
OEM able Windows installer
36x36 audio channel USBMLINK
USB bus powered option
Supported audio sample rates: 32KHz - 192KHz
Externer audio clock inputFirst class locas clock generator
Separate Clock Domain for digital input S/PDIF
S/PDIF optical/electrical, autosignal and frequency detection
USB 2.0 high speed 480mbps
24b Audio
16 x 16 channelKanal audio @ 96KHz
additional 2 x 2 channels for digital S/PDIF audio @ 96KHz
8 x 8 channels audio @ 192KHzTransparent 32bit S/PDIF out
DSD Format, support for USBDSD
ASIO round-trip latency less than 6.0ms
Microsoft Windows 7, Vista, XP support
Apple OS X supportASIO 2.1 and WDM support
Windows and OS X control panel
Inclusing complete channel mixer
OEM able Windows installer
36x36 audio channel USBMLINK
USB bus powered option
An externally hosted image should be here but it was not working when we last tested it.
Well, it's the same link, that was posted by mhelin in post#65. Everything about this products looks fine. It's asynchronous 2 local clocks design that in theory meets all quality requirements and it would be a real treasure for all digital xover crowd. That is, if one can handle 250$'ish price tag....
I wasn't able to find any comments or reviews of this interface over net, so no real life performance estimations of this particular demo board could be done. But it should be up to the task.
I'm still keeping my eye on new USB audio products from various manufacturers, but it seems like no big news on that front, maybe I missed something ?
If my memory doesn't play tricks on me, BrianDonegan from twisted pear have admitted (back in m2tech GB thread) that he is working on asynchronous USB solution, wonder how that's coming along ?
What really bothers me is Chinese manufacturers. I'm still wondering how they are not able to see this opportunity and make best seller product ? In musiland case, that means making minor changes in FPGA clocking out of I2S code portion, placing 2 el'cheapo crystals on board and naming it Monitor O3
Hi,
There are several chips for USB Audio Class 2.0 and full HD capability in preview stages from a number of the large chip foundaries. Non have gone into production AFAIK, mainly because non work under Windows and the Apple and linux market is too tiny. Until Micro$oft fixes their OS to allow USB Audio Class 2.0 devices to be plug & play I suspect all these companies will hang fire.
I have been discussing this and Apple Drivers with ML for bleedin ages. There are some barriers in the way these people operate that are pretty hard to overcome.
Ciao T
There are several chips for USB Audio Class 2.0 and full HD capability in preview stages from a number of the large chip foundaries. Non have gone into production AFAIK, mainly because non work under Windows and the Apple and linux market is too tiny. Until Micro$oft fixes their OS to allow USB Audio Class 2.0 devices to be plug & play I suspect all these companies will hang fire.
What really bothers me is Chinese manufacturers. I'm still wondering how they are not able to see this opportunity and make best seller product ? In musiland case, that means making minor changes in FPGA clocking out of I2S code portion, placing 2 el'cheapo crystals on board and naming it Monitor O3
I have been discussing this and Apple Drivers with ML for bleedin ages. There are some barriers in the way these people operate that are pretty hard to overcome.
Ciao T
I am pretty sure
the Rigid is not async. I believe this is the interface used in the new Audio Research DAC 8, and there have been reports that the DAC 8 sounds better through SPDIF than it does via USB. I guess I will do a little more research to get to the bottom of this interface.
Classic with MS!
the Rigid is not async. I believe this is the interface used in the new Audio Research DAC 8, and there have been reports that the DAC 8 sounds better through SPDIF than it does via USB. I guess I will do a little more research to get to the bottom of this interface.
Classic with MS!
Hi,
I am not an expert in this matter, but searching for a solution, transmitting 1024 separate audio signals from PC to the speakers. The project described at my Wave Field Synthesis and Holophony page.
By your opinion, the task would be solvable in the future, possibly at USB3.0. already?
I am not an expert in this matter, but searching for a solution, transmitting 1024 separate audio signals from PC to the speakers. The project described at my Wave Field Synthesis and Holophony page.
By your opinion, the task would be solvable in the future, possibly at USB3.0. already?
Thanks M$, again....
Hmm, sounds mysterious at least, maybe you could clarify this little bit more ?
If no LNDA stands behind it of course.
Wont argue on this, because there are not even hi res pic of the whole board. But, from information on official page, it's obvious that there are 2 local clocks for clocking in/out i2s to spartan FPGA and slaving clock option. Cypress EZ-USB FX2 is fully capable of async. and they are using proprietary drivers. If it is adaptive or isochronous design, I'm having hard time imagining how they pulled it off. Cypress or FPGA FIFOS would overflow in now time
Hi,
Basically, they feel they have a world beating product that sells well and do not see the need. I may have convinced on the subject of the Apple driver, together with their various importers.
Ciao T
Basically, they feel they have a world beating product that sells well and do not see the need. I may have convinced on the subject of the Apple driver, together with their various importers.
Ciao T
Ahhh... we are #1 (arguably) so why try harder. Ok, that's logical, but as I see it, there are no technical boundaries for them to implement this.
It's on page #1, additionally there was discussion about:
Koon,s soliution from '08, that was not developed further
M2tech EVO with it's "excellent" pricing
RigiSystems demo board
After some time, personally I reduced my list of requirements for USB interface to just 1 - it must be possible to slave it via external clock, and let it be just 44.1khz sampling. And still, it seems that only reasonably priced solution till now is Musiland. As Thorsten pointed out it is possible to synthesize almost exactly 24Mhz from external clock of 44.1khz or 48khz derivative. This means designing PLL for this purpose from scratch. Not a piece of cake, but doable even for diy'er. Even then, I suspect that performance would be not up to the level with systems like m2tech, that clock's out i2s using dedicated vco. Timing loop with such a design would be quite large, this means -> local clean DAC clock, lets say 11.289Mhz -> Isolator -> 24Mhz PLL -> USB controller -> Internall USB pll 48Mhz -> FPGA 2 stacked DCM's -> I2S out -> Isolator -> Reclocking Flip-flop driven by clean dac clock. It's quite easy to predict that random timing errors would be not a rare occurrence, even without isolator in path.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.