|
602
|
Ultimate Audio Playback / Your thoughts about the Sound Quality / Re: SQ of 1.186, best ever! (Again)
|
on: January 06, 2014, 01:59:02 am
|
|
Hi All,
I am going to go against the flow here, and say that I have been a little underwhelmed with 1.186 and Peters settings. At first I thought the sound was super smooth and liquid, but in the end I have come to think that the sound with Peters settings is too syrupy and has a number of shortfalls compared to the beta that I have been using.
Not good at all is it? Well, yes and no. I lost dynamics (lots of dynamics), resolution and transient speed and sound-staging (which went from staggering to merely very good). The sound that I want is infinitely fast with tremendous resolve and a faithful reproduction of voice and instrument alike, whether that be good or bad. I don't want details to be glossed over in order to make it sound smooth or analogue. What I was hearing with 1.186 and Peters settings was 'nice' and well tamed, but not really a faithful reproduction of voices or at least not the best that I think we can do.
So today I have played around with my old settings from the beta I was using and have changed a few things and am much, much more happy. The change for me is massive and I think that I am ahead of the beta now. The dynamics, presence, speed, sound-staging is back with interest. So I would appreciate it if some of you guys could plug in my settings and tell me what you think.
Cheers,
Anthony
|
|
|
|
|
603
|
Ultimate Audio Playback / Playback Tweaks and Source related subjects / Re: How I can lower the CPU to around 0.45 Ghz?
|
on: January 06, 2014, 01:37:21 am
|
|
Hi Juan and Georg,
I _think_ that Peters reported 0.45GHz is in part a function of Hyperthreading where the core is effectively split and runs at half-speed. For example, I have setup my Xeon processor to run at 1.2GHz in the BIOS, which is the lowest that I can clock it without messing with voltages (I think). When I turn on hyperthreading this 1.2GHz becomes 0.6GHz or 600MHz, which is somewhere close to Peters number of 0.45MHz.
From there I _think_ that Peter plays with voltages to further underclock his cpu, but I am not sure, and I also think that Peter is unlikely to comment too much here because as soon as he tells people how he has completed that last step of underclocking we will all be doing it, messing it up (because that is very easy to do) and then asking him for help with our computers that won't boot...a potential snake pit of problems.
Anthony
|
|
|
|
|
604
|
Ultimate Audio Playback / Your thoughts about the Sound Quality / Re: SQ of 1.186, best ever! (Again)
|
on: January 01, 2014, 12:37:52 pm
|
|
It does sound nice...I listened for a few hours at Peters settings today.
Peter, what has happened to the "trimpot" you were talking about in the USB Clock thread? Not ready yet? Or have I missed something obvious?
Oh, and thanks Peter. This morning was the first time I have had any time for audio in the last few weeks and I woke up to see 1.186 had been released...absolutely perfect timing!!
Cheers,
Anthony
|
|
|
|
|
607
|
Ultimate Audio Playback / Phasure NOS1 DAC / Re: Now I get it
|
on: December 29, 2013, 10:51:27 pm
|
|
Hi Glory, nice read mate. The thing that I usually find when the midrange is lush and beautiful is that the bass AND the top end are lacking, and are not diverting attention from the mids. That you score the Phasure so well in all departments to me really reinforces how well it produces the mids.
Cheers,
Anthony
|
|
|
|
|
608
|
Ultimate Audio Playback / Phasure NOS1 DAC / Re: USB Clock Upgrade My Experiences (so far)
|
on: December 23, 2013, 04:50:23 am
|
Anthony hi, We are both a little sad to be trawling USB protocol information  . I have posted these points elsewhere but they may help again here. lets assume for the USB link only that there might be four main forms of error / management interruption to data that could impact sound here (there are properly more, but for now). 1) Processing of resend requests (depends on usb transfer mode used) 2) Bit transmission errors 3) Audio word errors (out of sequence or missing words) 4) Transfer speed management requests USB Async transfer mode is intended for media stream transfers of video / data and as you say there is no USB protocol error checking, just signalling from the receiving end to speed up / slow down the link. So here the only point 1 of the points 1 to 4 above would not apply. The rest will apply and there will be no USB protocol handling / correction of errors so once the error has happened it will make it to the DACs as corrupt data and we hear it. Since the data lines are simplex (one set of wires carrying data for both directions) for the receiving end to issue commands to the transmitting end to speed up or slow down it has to interrupt the transfer. This is unlikely to be a "set and forget" tuning by the receiving end because the clocks at both end of the link will drift (I know even the temp stabilised Dexa clocks do this) which means that the speed up slow down requests will happen throughout replay. Another USB transfer mode is bulk transfer mode. If you read back and look at the hunting for noise thread you will see that this is mentioned. I asked in one of these thread posts IIRC if Peter knows from the source code of the NOS USB driver if bulk transfer mode is used by the NOS interface. This could be very relevant to what we hear. With bulk transfer mode there are CRC checks performed on packets and transfer resend requests are made where there are errors. So in this mode it is possible that all four error types listed above could be happening. The errors only have to happen at some thing like audio frequency intervals and we are going to hear the effects. Finally wrt clock quality and the accuracy of transmission over the USB lin. Again as mentioned else where both the transmitting and receiving end of the USB link synthesize their 480mhz transfer clock speed by multiplying the 24mhz oscillator wave form by 20X. This makes phase noise in the 24mhz oscillator VERY important if there is to be a well formed 480Mhz link clock. Consider if one beat of the transmitting 24mhz xtal is say 25% faster this could mean that for 20 beats of the transmitting 480Mhz clock it runs 25% faster than the receiving clock so 20 beats at the transmitting end to a relative 15 beats so 5 beats missed. This is an extreme (I hope  ) example, but its not hard to see that not having the 480mhz USB carrier running at consistent speed at both ends of the USB link could / will cause all sorts of data transfer problems. Taking all this into account my view was when I started with DIY clocks and then selected the Dexas was "how would better quality clocks not improve the USB link transfer quality ?" (actually I did have some experience of improving USB clock quality from years ago which helped. Then it was just a case of waiting for the free PSU offer that NewClassD run on Neutron stars from time to time to come round again) Its important not to go down the "data is data" route of thinking when tuning the implementation of digital audio components. Practical experience is that if you buy into the data is data approach then there are some really big improvements that can be missed out on. I think the best thing to do would be to use the information I sent over by email and take to plunge. Build the DIY clocks or put Dexas in. Don't get too hung up on transmission line lengths and noise etc. The effect of improved clocks is much much greater then the electrical effects. Three folks are up and running with Dexas with two more in the pipeline that I know of. Listening to the effects puts a very different perspective on the discussion . Kind regards, Nick. Thanks for the reply Nick. I missed the bit in the protocol about the x20 multiplication of the 24MHz clock to 480MHz...interesting...I will have to look that up when/if I get a chance. I guess my main beef with the DEXA's at this stage is the hideous cost (nearly AU$2000 for a pair buy the time they get here even with the *free* PSU - that is about one-third of the cost of the NOS1) and the less-than-optimal implementation (the wires). I don't know anything about their noise characteristics and can't seem to find anything on their website or elsewhere. If you have some data can you please post it? So I guess what I am getting at is I think that a comparable result can be achieved with more effort and much less expense by firstly figuring out the exact things that drive the improved sq and then developing a reasonably priced solution. After all this should be available to everyone and who knows, maybe we will figure out something else along the way that will improve things further. Personally, I think that yourself and Paul need to get together with Peter and measure some things and listen to some music. If these clocks are as great as they appear to be and if Peter has not already equalled it with his software 'trimpot' then we really will have a much better idea of where things sit. I cannot over-emphasize just how much I appreciate all that you are doing and on a lighter note how easily England have rolled over in the cricket (phew - we needed that). Regards, Anthony |
|
|
|
|
610
|
Ultimate Audio Playback / Phasure NOS1 DAC / Re: USB Clock Upgrade My Experiences (so far)
|
on: December 23, 2013, 03:20:11 am
|
|
Anthony's Controversial Thought #2
Ok, I have been flat out at work today trying to get finished for Christmas when suddenly I have this eureka moment: could the noise in the FIFO buffer of the NOS1 work in more than one way? This is the scenario...data is being written into the buffer and data is being read out of the the buffer at the same time. If we have 'correction calls' causing the FIFO to do more work than it needs to then in theory the FIFO develops more noise of its own...while it is reading data out to the dac! In addition to the noise on the ground plane, could this noise from the extra FIFO activity be hitching a ride out of the FIFO buffer with the music file?
A simple thought, but one that had not struck me earlier, and I apologise if someone else had considered this or if this is ill-considered in the first place.
Cheers,
Anthony
|
|
|
|
|
611
|
Ultimate Audio Playback / Playback Tweaks and Source related subjects / Re: Great PC Tweak - A Bert "Must Have"
|
on: December 23, 2013, 01:47:55 am
|
|
Coen, excellent stuff and quite timely too.
Great that you have given a second opinion about a lab supply onto the PPA card doing good things...I am glad we both agree on that point. It is interesting the things you had to do to get it that way though.
I am confident enough to say that not only does the quality of the clock on the USB card matter, but the the quality of the power supply and ground loops also affect things, most likely because they affect the timing of the clock and the regularity at which it spews frames forth into the USB cable.
This all leaves me thinking about the clock implementation on the PPA card (and Nick and Pauls DEXA clocks). I think we can do it better...the right clock on a USB board designed to better implement that clock (independent power circuits, layout of clock on board etc.) so that we can get away from wires between the upgrade clock board and the USB card as well as guarantee that the clock is as unimpeded as possible. Almost certainly this would cost a fraction of the purchase price of a DEXA clock by itself and we should be able to get it to sound at least as good, or maybe even better.
Anthony
|
|
|
|
|
613
|
Ultimate Audio Playback / Phasure NOS1 DAC / Re: USB Clock Upgrade My Experiences (so far)
|
on: December 22, 2013, 01:28:31 pm
|
I am thinking aloud now Peter, so please don't hold what I say against me.  So, we have a clock on our pc USB card that is spewing out information in frames (that contain the packets) at a set rate...sometimes it sends out data, sometimes it does not, but what the rest of the computer is doing (read latency) does not have a tremendous effect on the oscillator (the clock just turns over on its power supply and does its job) because if there is no data to be sent out it just sends out an empty frame with no packets just the timing information. If the USB bus operates at 8MHz there are 8000 frames allocated per second. Unfortunately there is no possibility of re-sending packets that contain errors because that will mean that the next frame would need to be delayed ( the reference is here). That is basic isochronous USB operation. Will a very stable, low noise clock/USB card make a difference here? Perhaps...at least that seems like what Nick and Paul are reporting to some degree. The very stable clock on the USB card is probably important from the perspective of it oscillating at the same very predictable rate relative to the clock on the NOS1 USB board in that it will not trigger a varying rate of 'correction calls'...I think that the only thing more important here than a stable rate of 'correction calls' is zero 'correction calls'. So a good low noise power supply for the pc USB card and a stable low noise clock are things to investigate in the pc. Controversial and ill-considered thought #1 - Does latency in the computer (i.e. not getting the data to the USB card buffer in time) affect noise because it causes empty packets to be sent to the dac when instead they should have been populated, thus causing 'corrective calls' to say 'speed up the transfer' and then once the latency issue resolves further 'corrective calls' are required to slow down the transfer rate....then there is another latency issue and the cycle starts again. |
|
|
|
|
614
|
Ultimate Audio Playback / Phasure NOS1 DAC / Re: USB Clock Upgrade My Experiences (so far)
|
on: December 22, 2013, 10:46:57 am
|
That no resends take place is a bit of s surprise for me because it would be the property of "sending data" which is subject to error checking (contrary to sending "audio"). Well, the error checking is obviously there (see NOS1 Control Panel), but then no resends ? I'll ask tomorrow.
My understanding is that a checksum is performed, but there is nothing to really be done with the result other that some sort of alarm that information loss has occurred, which is what the NOS1 Driver front-end on the XXHE PC tells us. That piece of information I got from post #52 here, so not strictly from a textbook. To be honest I was not game to post this information until I read that post today (John Swenson seems to have sensible things to say about computer audio in general) because I feared that I was not seeing the 'big picture' on the subject, but that post resolved my doubts and I went ahead. Sort of like all the pieces falling into place. Anthony |
|
|
|
|
615
|
Ultimate Audio Playback / Phasure NOS1 DAC / Re: USB Clock Upgrade My Experiences (so far)
|
on: December 22, 2013, 08:21:23 am
|
Ok, in the spirit of trying to understand a little of just what Nick and Pauls usb clock upgrades or Peters software 'dial' in the forthcoming XXHE release are achieving I looked into the asynchronous USB protocol today: I did me some book learning. In point form the following is what I have learned (please chime in and let me know if I am incorrect): - Asych is one form of the isochronous protocol
- All forms of the isochronous protocol function by the host (the XXHHE PC in this case) spewing out packets of data at regular fixed intervals (1KHz or 8KHz) and varying the number of bytes in the packet to suit the transmission rate
- There is NEVER any re-transmission. If data is lost for any reason it is not coming back.
- The receiver (the NOS1 in this case) welcomes the data into the FIFO (first in first out) buffer and clocks it out of there using a FIXED local clock. It is the fixed local clock on the receiving side that means that the transfer is asynchronous.
- The clock rates at the host and the receiver do not match...they just don't, even though they may be rated the same speed. When the clocks don't match the FIFO buffer will eventually empty or overflow both of which are bad.
- To keep the FIFO buffer within its population limits the receiver (the dac) will monitor the buffer and when needed send a packet back to the host (the PC) to say "whoa back" or "give it some spurs". The host then alters the number of bytes in each packet.
So if I have this right, the NOS1 usb board does a little bit of work monitoring the FIFO buffer and then sending back packets to the XXHE PC to say speed-up or slow-down. Then the USB card in the XXHE PC responds by doing a few calculations and changing how much data it throws in each packet. Now, the NOS1 is not your average dac. When XXHE upsamples to 16/705 that is 16 times more data than a simple Redbook transmission. On the face of things this means 16x then number of 'correction calls' sent from the dac to the pc to vary the transmission rate but this may be alleviated in full or in part by how much data can be made to fit into a packet. Peter will know this. So how could the upgraded clocks or software dials result in an improvement in sound quality? My guess is that by making the clock rates match each other more accurately that fewer 'correction calls' are made and therefore less noise produced in both the host and receiver usb interfaces which in turn has less of an impact within the dac and its production of jitter. The next question therefore becomes is there an advantage by having super stable and accurate clocks in the usb interface? My guess here would be "probably not" (nothing like sitting on the fence) because all that we should be trying to achieve is to absolutely minimise the number of 'correction calls'. If the two clocks cycle at constant speeds in relation to each other over time then the number of 'correction calls' will be relatively low. However the ideal thing here is to use only one clock for transfer, which is the slave idea that Coen, Peter and Nick had earlier. I don't know how to do this or if it can even be done in this situation. There may also be an advantage to using clocks that are super low noise in one way or another (I don't know which way really...just putting it out there). Anyway, this has been my attempt to put this stuff in more laymans terms for some others to try and follow. Please pick it to pieces and let me know where I am wrong and have not thought it through properly. Cheers, Anthony |
|
|
|
|
Show Posts
