Jump to content

OAudio

Members
  • Content Count

    32
  • Joined

  • Last visited

1 Follower

About OAudio

  • Rank
    Freshman Member

Recent Profile Visitors

268 profile views
  1. Indeed, Its 3000 odd pages long but there are a few gems in there. It was bedtime reading for me for some time when I was working out what platform to move to after developing the X99 server. Sign of an obsessed audiophiles I think 😀
  2. Hi, My first post in this epic thread so hello to all ! @StreamFidelity hi, perhaps I would not go as far as saying this is "solved". It is an excellent starting point, the C620 architecture is the best I have come across so far and in large part I think because of its clock subsystem design. This comment applies to Intel systems, I haven't used or looked deeply at AMD. The C620 is still a starting point for me however. A few posts further down in the "Building a DIY Music Server with custom made parts" thread I also say. "I used to use expensive commercially available clocks but found that they do not meet the specifications I want so I build my own these days. There is simply a huge amount or work needed to work out how to make a clock really work well within a specific audio server environment." The latter comment was in part aimed at my C621 server design. C620 servers can give absolutely great sound out of the box, but things can still be done to improve the system's timing, both with and without use of a clock. I would not be surprised to find Taiko has done the first steps I have in mind but its possible to go past this but IMO getting to the very highest performance is not a bolt in operation. The issue I found was that C621 boards can be ultra transparent and applying the wrong clock design or put the right clock in but applying it in the wrong way can give beautiful music but unfortunately with standout problems from the clock implementation. The musical equivalent of owning the Mona Lisa painting but with a boil painted on her nose . It took more than 3 years to develop the clock I use now in my C621 server, but the musical results are nice. So perhaps timing is not completely solved but there is now an excellent starting point with the C620 boards. O Audio.
  3. Its not nice at all when a board dies without an obvious reason. I am not sure if clock replacement is a regular modification so apologies in advance if the following are things you know / have tried. CPR for the buffalo, just make sure you have a mask on they can be gooey around the mouth First voltages. Were you able to check the peak to peak or RMS voltage from the output of the Xtal that was originally on the board ? These days 0.8 - 1.2v peak to peak clock voltages are not uncommon as VCore voltages get lower with internal processor frequency getting higher. If the Pink Faun is say 1.8, 3.3 or 5v output then there is a good chance that the processor might not be starting or worse be damaged due to the pk - pk clock voltage exceeding the rail voltage of the clock input logic gate on the chip. Try looking at the data sheet of chip you are clocking. Assuming that the voltages are ok, (but try the following anyway). The Xtal that was removed probably had 4 SMD pads. Identify the GND pins or N/C pins with a meter. This will leave 2 remaining pins that the crystal was connected to. Inside the chip you want to drive there is most likely a hex inverter logic gate that is there to drive the original Xtal. The inverters inputs are connected to the two clock input pins of the chip / pads where the original Xtal was installed. One of the input pins connects to the on chip inverters output (this is the pin you need to drive when inserting the clock signal) the other is used as to drive a feed back loop around the chips inverter (this pin will most often not accept an internal clock input). Most often the only way to determine which pin is the correct one to use is to try both out. There is a 50:50 chance of nasty "moment" with expensive bits of kit when adding a clock where the board appears dead only to resurrect itself when the correct pin is driven. Finally looking at the Pink Faun you are using in the picture it looks like it is magnetically coupled on its output. If you think over voltage might be the problem you could load the Pink Faun's output pins a little just to pull down the pk to pk waveform levels. As a diagnostic it doesn't need to be anything elaborate just a small resistor will do I would start by trying 200 - 100 - 50 ohms. This would not be a good think to do long term for best timing performance but as a diagnostic it might help you to understand what is preventing the board from starting. Hope this might help to resurrect the beast . OAudio.
  4. Black would work better for heat emission from the CPU cooling block, but the extra heat emitted would be inside the case rather than being transferred out of the case via the heat pipes / case's external heat sinks. I don't think the difference between black v's silver finish should be too great so aesthetics will probably be the decider . Black would look cool though.....
  5. Hi, Details are finalised and the my engineers have a production slot scheduled to cut the coolers and other parts (below) from billet in two weeks time. I still have not decided on colour of the finish either black or clear anodized. I plan to visit the factory to see some finish samples and look at the units in production so will confirm colour then. The rendering (in the above post) shows the cpu "riser" and its clamp for the securing heat pipes. In addition I am having four half clamps produced per riser. The half clamps are used in pairs clamp three heat pipes and allow them to be bolted to whatever heatsink is to be used for disipating heat away from the server's case. The correct hardware to fixings will be used to bolt the risers to the standard LGA3647 motherboard socket fitting and I went to some lengths in the design to ensure that the plastic CPU retainer that is used on LGA 3647 coolers will also work as normal. I have had to commit to a batch of production in order to get them made which has not been cheap ! There may be a few sets left over that I do not use for my project. Will keep you posted when the physical unit show up in a couple of weeks. OAudio.
  6. Hi All, This is a rendering of one of the parts I'm making for packaging of my audio server development. There are a few final details to iron out with my engineerings but they will start cutting them from billet in the next couple of weeks with luck (waiting to get a production slot agreed). The cooler is designed to handle up to 200 watts of dissipation from an LGA3647. This is far higher than is required even for heavily loaded CPU. At 200w you would need a < 0.2C/w rated heat-sink which is a very large passive sink, but this is not really necessary for an audio server ). Care has been taken to make the heat pipes exit the CPU's footprint area 40mm above the motherboard. This means that heatpipe routing remains simple and most sensible sized memory DIMMS should be insertable and removable without moving either the cooler or heat pipes. It can be reversed by 180 degrees when fitted meaning cooling pipes can exit over either bank of memory. I dont need this feature but it just seemed a good thing to do. End point clamps for the far end of the heatpipes are also being produced. Material will be engineering grade aluminium with clear hard anodizing to keep it looking pretty as time passes. OAudio.
  7. @Nenon A few thoughts, its possible you may be looking at something a little different then you are expecting. Caps. The M-Lytics will be 47k uf. The server is described elsewhere as having approximately 0.7f in total. Maths says approx 47k uf per cap give or take. They can be difficult caps to apply in such large size for servers, personally I have found they slow musical response and its difficult to keep life and air in the music using them. Credit and respect to Taiko if they have found a way to apply them without these issues. Looking at the thermal design and power supply. Whilst the case has heatsinks that are proberbly ~ 0.5k/w dissipation on each side, there is no dissipation acessable directly from the power section of the design. It may be that heat conduction is through the base of the case to the heat sinks but this may not be not very efficient. If the at least the main rails were powered by multiple linear supplies dissipated heat would be 40 to 60 watts + or - from linear supplies. It' clear the CPUs are well catered for by the side finned heat sink but looking at the thermal approach my money is not on linear supplies. Based on the thermal packaging and layout of the visible supply elements, I would go out on a limb and guess that there could be buck convertors under the caps, even a DC ATX - which SGM servers have used previously. If you know how to modify them well and apply them optimally their sound quality can be much better than people generally realise so I would not regard this as a limitation if they are used. Transformer. If the thermals do point at bucks for the main high power rails then 400va would be a good size for the power requirements of the server. The choice would be helped by the CLC input filter which will increase the power factor of the supply easing the life of the transformer. I find the sweet spot for server transformer sizing a VA of 2 to 3.5 times the stable VA total draw of the server (consumed + disipated power). Go large and sound becomes slow and stolid. Multiple transformers need careful thought and design if the key aim is to maximise sound quality. The issue is that the power factors of linear regulators that supply key server rails tend to be low leading to high peak currents in transformer secondaries, particularly when using very large capacitances. Where dual transformers are used it can lead to each transformer having a different distortion caracteristics under their respective low power factor loadings which in turn can apear as differential noise between the rails which are supplied by the different transformers. It took a long time and a lot of work to pin this down. An example sound quality impact might be if you have ever been suprised that you get a better sound powering say a clock from the servers main trafo rather than its own dedicated "clean" transformer, there could be many possible causes but look carfully in this direction first. OAudio.
  8. Hi Alex, Thank you for the warm welcome . I know you are already on your second iteration of a solution for USB transmission with the ISORegen, I love the concept. I read the white papers when they were published and thought they were brilliant at the time. They are a great compendium and analysis of influences on USB sound. It's refreshing to see such valuable information coming out in papers. I'v heard the ISORegen once, unfortunately at a show in a system components I had not heard before. It was very good but I'm looking forwards an opportunity for a longer listen at some point. I actually owned a Silanna + PHY hub design but not as meticulously designed and implanted as the ISORegen (actually I bought the unit because I needed to source an ICE08USB chip for some repair work !). If I explain the general approach I am pursuing for USB in my system, it might help understand the scope of the SI testing I am doing. Experience over time has lead me down the route of doing what I can to keep the USB data's journey from PC (CPU) to DAC as simple as possible. This has meant a lot of work in the audio server to ensure good USB timing and power (clocks and PSUs are to my own designs). The work has helped promote a well timed USB stream and good USB SI from the server. I should mention that at the server's USB is handled by its PCH chip as this is not that common an approach any more for very high quality sound. Indeed its a break for me after years of testing and screening different USB chipsets and working on boards etc, but my server's motherboard was carefully researched and modified and the sound its providing now is remarkably real. The one exception to this simple approach is USB isolation. Like many I also think this is nowadays a necessity. Of a few isolation solutions I tried, by far my favourite for sound quality have been the Silanna ICE08USB designs (I know this wont be a surprise). Happily the DAC I have has this on its USB input as a standard feature. The Silanna then feeds directly into the DACs internal USB interface without further processing. So just two clock domains the servers USB clock and the DACs PHY clock. There's a lot of lower level detail in and behind the but essentially the above is the set up I am working with. The point that sparked spinning up of the test board was this: Of two identical good USB cables, one 1m the other 0.5m, the shorter is clearly better to listen to (not a revelation maybe others have found this too). There are lots of possible reasons but having already played around with the ICE08USB a little and after this experience with the shorter cable (better SI ?), I want to practically see if there are any sound quality upsides available from improving signal at the ICE08USB inputs. The board I have spun follows my keep it simple approach. Its not a PHY Hub design like the ISORegen which works for me as there is no packet processing or most importantly for me added clock domain that will interact with the clocking design I have in my server. The board design is analogue and should achieve extremely low transmission latency. I am keen for it to be as transparent as possible so the server remains the main influence on the data stream. So not that similar to the ISORegen other than the SI conditioning you seem to be achieving with the PHY Hub's output. I happened to be sending some stuff off for fab and though it might be fun to spin a board to try this. Of course if your going to make the effort its sensible to build in flexibility to play with power options and shield setups which is know is well trodden but still important. I don't have affiliations but do have a [very] strong desire not to listen to digital distortions in music. I'm quite happy to get stuck in and develop and build stuff if I think its going to help achieve this. My background was research scientist then software, IT / Telecoms. I ran a global solutions business supporting System Integrators until recently. I am on sabbatical just now which means I possibly have a bit too much time to peruse audio . Cheers, Nick.
  9. Thanks its a very interesting read, Timing, Signal integrity (inc transmission, detection and cable effects), PSU influence, Onward processing, and USB transfer & error handling, all hotly debated :-). I think the excellent white papers @Superdadlinked above pull these into a broad and cohesive picture. OAudio
  10. Mocenigo hi, Bit error of 10^12 would do the job for sure...."if" you can get to this performance in a real life implementation. Personally I think there is a lot that needs to be taken care of in PC to DAC system set-up approach this. As I mention above the USB transmission eye detection margin is quite small for the receiver (DAC) at ~ 0.4v. Differential noise between the power supplies of the USB link's transmitter (eg the PC, packed with noisy buck convectors, high transient loads and even an SMPS if your unlucky) and the receiver (the DAC probably on a low noise linear supply) really have the potential to impact eye detection margins. Although the USB cable is shielded, there is also generally a GND loop between the PC and DAC via mains safety earth connections. The PC switching supply noise and ground leakage currents can pollute the safety earth and appear at the USB receiver circuit in the DAC (even though there "should" be a good ground reference established by the USB lead's shield). Then there is EMI coupling into the D+ D- pairs as they traverse the motherboard, if motherboard is used, or from a PCIE card if used. EMI can also be coupled into the USB cable. I have much frustrating experience of "good" quality coaxial cable being insufficiently shielded for low jitter HF signalling. Interesting here is that there are so many reports in forums about improvements in sound from multi shielded USB cables, something I use here too. Final area I think is very important is transmission timing both phase noise and clock speed. The differential noise above may or may not be enough to cause data errors due to eye detection errors. Even if errors are not being caused by detection errors, the differential power noise in the transmitter's & receiver's supplies will cause threshold detection jitter in the USB data stream and this does matter to sound quality (although I would agree this is not data error). I mentioned in my earlier post above I have developed the ability to accurately set the relative frequency of the individual USB clock domains governing the transmitter and receiver. I have been working on this stuff for many years, and know that as little as an 0.000005% difference in the speed of the USB transmitter and receives clock domains can be heard. USB timing really matters if you are aiming for truly high end sound quality. The point of the diagrams below is not to highlight that using a 3 or 5m cable could be a bad move (most people just don't go that long for audio :-) ), rather my point is something as simple as the cable length alone can really degrade the eye detection margins. The issues listed above I think have far greater potential to harm eye margin performance than these example cable lengths. sample USB transmission eye 9 inch cable eye 3m cable eye 5m cable I don't have USB test equipment (way too expensive) but I have been modifying USB interfaces and audio servers at board level for > 14 years. I just can't say beyond doubt that the above issues cause actual errors but I have come across lots of evidence that the areas above really matter for quality. I happened to be working up that board I posted about above prior to seeing this thread.I though it would be fun to post about this. It is able to do much more than condition power and make or break shield links etc. I felt its worth the time to see if anything useful can be pinned down. Best regards, OAudio.
  11. We are on the same page :-) The board is set up to be able to be switched between these options and to examine some ideas to manage transmitter / reciver differential supply noise. I have used this approch in other projects but lots and lots of unknowns with USB transmission so practical testing seems the best way to go.
  12. Hi Sandyk, Thanks for the thoughts. My rendering software can't show the second daughter pcb. The second board has a 4uv low noise regulator and option are built in for where it is powered from. I can use this / the PC supply in different combinations for transmitter and receiver bus power. Transformer ground current is a tricky one, its influance is going to show up twice if Im not mistaken from the PC supply and the DAC. Theres quite some thought behind the approach in both these areas but perhaps best to get the board built and tested then go into some more details.
  13. Beerandmusic, this is a very interesting thread. I am relatively new to the forum so its just caught my eye. It's very interesting that asynchronous transfer errors are not resent meaning that it is possible that data can arrive at the DAC uncorrected. I also think that the vanishingly low errors rates that are quoted earlier in the thread may not truly reflect how a real music system's USB interface performs. The low error referenced by the USB standard assumes that transmission conditions meet the USB standards signal eye specifications all of the time. But, consider that successful transmission of music data relies on maintaining USB transmission eye quality on the 480mhz carrier and with differential D+ D- signal amplitude of ~1v. When you look into the logic detection thresholds they are as low as 0.4v and this at 480Mhz down say a 0.5-1.5m USB cable. The transmitting (PC) and receiving (DAC) systems are driven by entirely different power supplies (differential power noise between these two platforms impacts threshold margin, already say just 0.4v, at the receiver). I use USB between PC and DAC with D+ D- USB isolation at the DAC. I also (intentionally) have the ability to match the clock rates between the USB transmission (PC) and USB receiver (DAC). I think the set up of the USB link is pretty good, certainly sound quality is very good but I agree with your list of possible problems (above). So I have taken the step of designing this in line USB board specifically to look at some of the factors in play. If it works as intended it will allow USB signal, power at transmitter / receiver and shield continuity conditions to varied whilst looking for subjective sound quality change. I don't know if this approach is going to generate useful outcomes but faced with so many possible factors, a practical approach might narrow things down. The PCB is produced and on its way to me and I have to populate and test, but fingers crossed that the effort produces useful results. OAudio
  14. Some good points being made here. Personally I ended up spending months and months on the characterisation of motherboards power behavior to be sure of capturing complete requirements (mentioned a little of this is the earlier post). As well as longer duration trace recording its important look extensively, in both time and frequency domains, at real time behaviours. Understanding dynamic behavior and relating it back to what is driving it in the PC is very important. Some systems for instance will throw out a mSec transient current spike as POST completes and processors are initiated, easy to miss but similar in size to maximum draw on the EPS rail at maximum CPU load. You could almost weld with some of the LPS prototypes I made up during development. I tried a variety of designs based on different devices types and topologies to understand what works best. It was lot of work but, but important to properly understand what actually delivers optimal SQ. I'm glad to say (at last) that the supplies are finnished on smart PCBs. OAudio
  15. Martin hi, I used early Plextor M.2 SSDs for a while. They could be bought with the M.2 memory stick mounted to a full height PCIe card. The riser card looked easy to modify. This is just a random PCIe SSD card selection (I haven't researched it) but if I were trying to do I might research a card like this to see if the go faster shroud can be removed. Applying power means cutting traces from the PCIe board and wiring in your own, I am sure if this is something you would be comfortable with. https://www.goplextor.com/Product/Detail/M9P(Y)_Plus#/Spec A riser board with a power socket would be helpful, but is not something I would normally look for as I tend to modify boards directly if needed. Regards, OAudio
×
×
  • Create New...