Jump to content

Wavelength

  • Posts

    688
  • Joined

  • Last visited

  • Country

    country-ZZ

2 Followers

Retained

  • Member Title
    Junior Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Rick, Bulk mode is just one of the modes of transfer for USB. This is the same method that is used in hard drives and other error correcting protocols. Basically all data is sent the same way on USB. The modes only change the way the host and device react. In the enumeration phase of any USB device the host and device agree on how they work and what they work with. Most controllers handle 7 in and out and the root or what we call End Point 0 is what the device uses to exchange control information. So basically what PET does is tell the computer it is both a BULK-non hard drive endpoint and a ISO USB Audio Class 2 device. Of course now PET has to have drivers for every OS possible now because no OS supports BULK audio. Is this better? PRO's yes the host will retransmit packets until the device receives valid data. CON's The big one is that BULK has a low priority, ISO is the highest. PLUG.... yes the host will retransmit packets until the device receives valid data. That means more noise, more power and well less quality. The bigger problem is that they have to have custom device drivers and we all know what that means. Thanks, Gordon
  2. All, I have the original Rebecca Pigeon CD, 24/96, 24/88.2 (like best), Bob Katz 24/176.4 and Chesky's 24/192 versions of this album. I am really impressed by the sonics of the new MQA CD. David Chesky sent me a copy before it was released. I then went to amazon and bought 10 copies. I have sent them to musicians and recording engineers I support. Everyone is really impressed and you can really get a feeling of the differential that MQA can have on an audio track. I played the track in iTunes as 16/44.1 then with Audirvana Plus and the difference is night and day. Thanks, Gordon
  3. Jonathan, Actually phase has nothing to do with any of these interfaces. USB, Asynchronous only is used as a flow control to assure the data at the endpoint does not over or underrun. The data is received as samples and then the selected Master Clock streams out the data I2S to the dac chip. Since the Master Clock is the same at the DAC and the interface, then phase is not an issue. Ethernet (networking same for WIFI) UDP frames are received by the endpoint and control frames are sent back to the server and this acts as flow control between the host and the endpoint. Then again the same thing happens as above... The data is received as samples and then the selected Master Clock streams out the data I2S to the dac chip. Since the Master Clock is the same at the DAC and the interface, then phase is not an issue. Firewire audio is only asynchronous if you are using the Metric Halo stuff, otherwise it is using a PLL, usually the good JET PLL, but none the less it is a PLL and that varied derived Master Clock is used for flow control of the data from the host to the endpoint. ~~~ There is all kinds of pollution that effects digital stuff. One of the reasons why I developed the JitterBug. It wasn't to get rid of audio interference it was to get rid of the noise that effects digital circuits. Well one of the 3 reasons. Digital noise can effect the lower digits on any converter, this is why signal to noise ratio is different from vendor to vendor even when using the same DAC chip. There are a boat load of reasons and a band of noise that can effect this. Take for instance DSP's, FPGA's, CPU's that use a PLL's to function as working clocks. PLL will create ground noise that can effect the way the DAC chip performs. A long time ago... 1986-87, I designed a SPDIF DAC with two DSP processors. They used a PLL to basically create parallel processing. Well believe me it took six months to get that sucker working as that noise was really throwing things off. This is a big subject to tackle on a forum. Everyone is going to have their own experiences, reading of XYZ, thoughts etc... Really don't get all focused on stuff like this, unless your designing real products and then you can tackle these problems one at a time. Thanks, Gordon
  4. Do you have exclusive mode set in your Tidal configuration under DragonFly? Ghost Stories is 24/96 so your probably seeing magenta and not Purple which indicates MQA. Blue means 48K sample rate at 24bits. Thanks, Gordon
  5. DragonFly enumerates with a dB scale. Therefore full output is 0 down to -64dB and then it mutes. Thanks, Gordon If you are using the 1.06 version of software on the DragonFly then you should contact Tidal support to see what might be the issue. It may not be volume, but you could check that by running Audio Midi (found in your utilities folder). It will show the actual volume setting of the DF at the time the song is running. You can also change it there... but I do know there was a bug in the Windows software so I would imagine one in the macOS as well. Either way you would be narrowing down the problem. Thanks, Gordon
  6. Jonathan, All interfaces including Ethernet have a problems. Ethernet 1000 and higher especially have problems. Because unlike 10/100 were you have a dedicated differential pair of transmit and receive. You now have bi-directional 4 bit data and things get a lot more hairier!!! Thanks, Gordon
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
×
×
  • Create New...