• Content count

  • Joined

  • Last visited

About Wavelength

  • Rank
    Junior Member
  1. Jonathan, Digital cables of all sorts have different effects on the device system. In the past SPDIF cables were all about jitter, but really recovering the clock from the data stream was only half of what was required. With USB it comes down to a couple of simple things that can make all the difference in the world: a) Data integrity, impedance correctness, eye pattern, low capacitence etc. Basically how well does the data get there. b) VBUS/Ground how well does VBUS and ground get to the downstream device without effecting (a) above. c) Computer noise, all cables can transmit noise, some cables will throw that noise back into the computer some will throw it at the device, which of course is really bad. ~~~ I have tested a boat load of cables here. Some over $1000 could barely work with some of the dacs I had here. Some $10 ones worked really good and better than others. The big problem I have with cable companies is that nobody owns the test equipment that I have to test these cables? Why not? Thanks, Gordon
  2. Jonathan, Trying to fix a USB problem with one solution is never going to work. This is going to sound like a freaken marketing answer, but... You have basically 5 variables that can interact with each other: Power USB Cable Data integrity USB Cable power Device Host #5 Ok so everyone knows that not all USB host ports are not created equal. Some are off the main host controller, others off an internal hub with other BS on it. Second not all brands are the same. I always double back on my days designing motherboards and the fact that there were 2 accountants that shared my work space. Not to mention that these things are made for a price point, but also you have to look at the engineering. Were is the motherboard, were are the ports, are these cabled? #4 How well is the downstream port designed? I designed a product for a company one time a rather large company who had their contract manufacturing make some prototypes. The company called me up &%&^%$%& me out. I said send over the schematics and a sample. Crap I am not sure if my reference design was even understood by the company. USB is a differential pair, they had the + signal go like 2" longer than the - leg. It would hardly work Full Speed. 3# Power can effect #2, but it can also be effected from outside noise. We have all seen the split cables and the thought that this fixes the effect on data, but some of these missed the other points. 2# Look the cable is a huge variable. Even I have learned a bunch in the last 5 years of my 14 years in USB. Well lets face it Full Speed is pretty easy to pull off. Most of these companies took their SPDIF cable and added VBUS & Ground. We even saw companies trying to sell 50-60 foot cables. They hadn't even tried these with DACS, let alone Asynchronous ones which require bi-directional data. On the Tektronix analyzer and a TDR you can test these pretty easily with known Host and Device. 1# Power... part of the problem with USB is the common ground. So in the basic sense the computer ground is shared with the USB and the other devices connected to that USB cable. Isolation will fix that problem. But what effects does it have on the rest of the system and were do you isolate? Do you isolate at the I2S or at the USB? The problem with the Silanna and Analog Devices isolators is that they do not reclock the data and therefore any USB Jitter on the data stream coming in will be increased on the other side. This is why putting a HUB on the device side is really necessary. That will reduce the data errors, but can't fix the data errors. At least with I2S isolation you can reclock the data with the known Master Clock which is synchronous with the data and hopefully low jitter so the dac sees exactly what you want it to see. For me I run my power for my system (WWWS speakers, WA Corona Silver VT52 amps, WA Sine6 pre, WA Crimson or Cosecant, MacBook Pro Retina 15, Drobo Quad SSD raid Thunderbolt) as a spit system using CG T filter. One to the mains, one filter to the digital MBP+Drobo+isolated ethernet switch, the other side amps, dac, pre. This way the digital stuff has to go through two filters to infect the other side. I plug my DACS through a Sonnett Ethernet/USB3 Thunderbolt dongle. It works better than the MBP ports. Cables USB AudioQuest Diamond or Curious. Thanks, Gordon
  3. I have a mint 3561A yea with the bubble memory. It's a great piece for testing low noise analog stuff. I also have a Stanford SR760 which is a little better. The problem is getting the phase noise into these. I have a Symmetricom phase noise analyzer that we use for testing crystals and oscillators. It's got a custom downloadable FPGA in it and a 10MHZ super low phase noise reference in it. We get good plots to 1Hz with this. Before we had that it was kind of hit and miss using a boat load of reference stuff. Thanks, Gordon
  4. Ok, Some of the top end SOC's have PCIe and SATA. I have worked with the ARMADA 7040 which has both. The larger ARM chips like the Armada, double digit ARM like the A53 the 64 bit units and so forth are great for network bridges, NAS drives and stuff like that. They are not very good at Audio. Doing Ethernet in an FPGA is not something I would try. I bet if they are using an ARM processor on the board the Ethernet is probably going there. As I said low in terms of sample rate. Full Speed is limited to 32/96 stereo or 2ch. High Speed USB is limited to 16 channels at 32/192. Or 8 stereo channels at 32/192 or higher rates with less channels. 4 stereo channels at 32/384 or two stereo channels (4 ports) at 32/786. But remember with higher sample rates, means more data being pushed through which does equate to more USB errors. Thanks, Gordon
  5. Ok guys a few things... First Audio Jitter/Phase Noise is measured from 10Hz down. Most jitter analyzers you see like the microsemi is used for communications or other stuff. Good high speed scopes with EYE pattern and differential probes will tell you a lot about USB, Ethernet and other protocols. Still need a 5x scope for that with a lot of storage. Ethernet is a good protocol, not great for streaming but non the less it is isolated and capable at 100Mhz speeds. The controllers are good at 10/100 and some of them Microchip MZ, i.MX6, Renesas RZA1 etc.. are good choices as they have I2S capable outputs. A number of the ARM processors do not have good I2S interfaces. The processors listed above have very good I2S. The other ARM processors do not have good I2S and need to have FPGA's or other logic to lower the I2S jitter. The problem with more powerful processors such as say an A53 which has 10/100/1000 Ethernet is now you have processor noise to deal with. Isolation becomes and issue and expense. Ethernet does require a protocol and even tough there is AVB, in our case the Roon code is probably best. UPnP/DLNA is hit or miss in most setups. I have a Thunderbolt license and designed a few things. I have the v1, v2 development system here chips and so forth. Thunderbolt is basically a wired extension of PCIe. Some companies in the pro industry are basically doing USB and Thunderbolt. They have a USB multiplexer on board and a USB Host controller hooked up the the Thunderbolt bridge and can select one or the other interface and then that goes to usually an ARM processor and or DSP (can be FPGA) to do all their stuff. Is this better? Well you could argue that Thunderbolt could be a more controlled setup and I bet it would be. USB, USB3, USB-C we made USB easy to work with. We created platforms that allowed digital and analog designers easy access to build their products. Full Speed sure is ceiling is pretty low at 32/96 being the max stereo sample rate. High Speed sure is limited to sixteen channels @ 32/192. USB SS is pretty much wide open. The big problem here is isosynchronous is not error correcting. You could create a custom protocol that is error correcting but really with the error rates on a well constructed system being pretty low there really is no need. ~~~ Were at a point in audio were we are moving sideways. The DAC chips really are having enough problems at 384 going to 768 is just silly. So we are giving the customer base different connection options. There will always be ways and products that will better the listening experience. Really I have boxes of shit all the way back to college. Who remembers the sharpie product that you would apply to the outside rim of a CD. Basically the green was suppose to inhibit stray laser bouncing that would effect the receiver and cause less errors. This is a niche market area of high end audio that will never go away. No company can be sure that they get everything perfect in computer audio. They can't because there are too many variables. Some do better than others, that's the way it is. Buying and knowing how to use test equipment is something you should leave to Stereophile. John has spent decades working with Ap, Prism and other companies creating test suites. Buying inside a group to do testing would first require that you totally understand what it is you are testing. Just think of what would happen if you guys did testing and the results were XYZ. Do you think that this would be argued over and over again and really what would that accomplish? Probably nothing... Thanks, Gordon
  6. Guys, There are 3 types of USB testing equipment available. The most basic of test is the protocol analyzer. These are available from TotalPhase, ITIC and others (I have those 2) $500-$1500. The second is a USB compliance analyzer. This is what companies use to determine the basics of USB. These go between a computer and a device. My Tektronix version of this cost about $18K. It's not really good for testing how well things are working. But you can set this up and see more information than a protocol analyzer can. You can go a step further with Tektronix and I have been working with them on this so that you can test real time between devices. Look at EYE patterns and stuff and calculate USB jitter (not to be confused with digital audio jitter). The big problem here is on HS/FS devices you really have to sit down and take note of who's talking. Remember it's a bi-directional bus system. Anyway this adds another $10K on top of the compliance testing for HS and don't ask category for USB3 stuff. But really what's it going to tell you? You bought the wrong product? Why not spend the money wisely on something else? Thanks, Gordon
  7. Peter, Thanks, this is exactly what I have been saying! mansr, really you can look at the code all you want, your only getting 1/2 the picture without knowing what they are doing on the master side of this. Plus what we are doing on DragonFly may have nothing to do with what you have seen or reverse engineered. miguelito, It's impossible to update the firmware in the ESS DAC chip that would require a metal revision. Everything we do is in our code. Also again, non of the unfolding is done in the DAC chip. All, Hey it's been great here for the most part. I am going to leave now. I have some guitar amps to build, finish up a tube DI + optical compressor and some other projects for Barenaked Ladies, Tom Tom Club, XTC and Melodime. Thanks, Gordon
  8. Peter, You don't need another DAC chip to do this. There are several ways after your NOS DAC chip to do volume. Like what I do is put the volume control between the DAC output analog domain and the output section. Usually in my case a Tube Buffer or transformer coupled tube section. Peter won't know unless you try. Thanks, Gordon
  9. Peter, I make NOS DACS as well. I will probably not put MQA on them. They are what they are and stand alone in the way they sound. Sure you can still play MQA tracks on them as you can with other DACS that don't have MQA support. E? I am a little confused... I take it your talking about DSP filtering before it hits the DAC or between the render application and an MQA capable DAC and the interface (USB, other). Correct that or digital volume will manipulate the data and not create an MQA bit true stream to the product and will render the MQA non-compliant. Peter, you can design into your product analog volume controls like others and myself have done and over endpoint 0 have a system wide volume control. There are many ways to do that actively and passively. Peter, you could also entertain having digital filters and a NOS DAC. Remember digital filters were originally conceived for Low Pass to remove all the unwanted crap. But remember MQA might be using Filters that are not of that type. They might be for other areas of the listening area. I really don't know this to be true but this is very possible. It would not effect the NOS nature of your product and you still could be MQA compliant. Your in control of your products. If you wanted to do MQA, I would talk to them and see what they have to say. Thanks, Gordon
  10. again, this is why we should not listen to people who speculate how things work. mansr, there is example upsampling code and libraries available for the MX processor. Even with MQA running we would be able to add another 256tap x2 (stereo) upsample if we wanted to. But that would just waste power, increase system noise and lower the overall quality of the experience. Thanks, Gordon
  11. So that the DragonFly can do the second unfold and with the MQA libraries match the MQA Filter for that track inside the the ESS DAC chip. Remember MQA is preserving the authenticity of the music. Think about it that way! So if you are playing some 24/96 file in standard PCM format in XYZ file type (i.e. AIFF/WAV or FLAC/ALAC) then you get that in DragonFly using minimum phase filters built into the ESS DAC chip. If you get an MQA file it will be unfolded on the host application delivered to the DragonFly over USB and inside the MQA code on the DragonFly it will be unfolded and presented to the ESS DAC chip with the Filter that matches the track. Thanks, Gordon
  12. Sorry but I did not say it was Windows only. MAC has both Tidal and Audirvana which I have stated a number of times. Thanks, Gordon
  13. Ok this is a bit of a confusing question... Tidal, Audirvana and soon to be other renderer capable MQA applications will do the first unfold of the track. Is that your question or something else? Thanks, Gordon
  14. First DragonFly's max sample rate is 96KHz. So the data going to the dac cannot exceed that. Others here will say they know what goes on here, but I will say I don't. I don't know what the application does in the case of sample rates above the 96K threshold of the dac. Sure I could guess as they do, but I would rather not mislead you. If the MQA LED goes Purple then you know your getting the best possible results from the file you are playing. Thanks, Gordon
  15. I just answered that above... so here it is again: DragonFly is a renderer version of MQA. This means the first unfold is done in the application. The second unfold happens in the DragonFly processor and sent to the ESS90xx DAC chip with custom filters that match the track being played. As far as the content (i.e. original sample rate etc...), it's best seen in Audirvana as they spell out the data rates of the original track. Thanks, Gordon