pj

I'm in the same boat - I was looking at some high grade PCM63's but they are selling $125-$150US per chip. The factory Pass D1 had a PCM1704 upgrade and when I built the DAC in 2008/9 the 8 x PCM1704 required would have been affordable enough to DIY the equivalent, but now I'd be looking at in excess of $800US for the chips alone. The measurements are done using a sound card and software, so it doesn't require much kit. The main thing is that because the gear isn't calibrated to lab standards the results are best looked as comparative rather than absolute. One of the reasons I've got back into doing this kind of testing was to look at the influence of SPDIF converters on jitter levels. I'd bought a Welborne Labs LPSU for the Konnekt 8 and could hear distinct differences between wallwart powered and LPSU. The result was a lot darker sounding and I was curious to see how the LPSU was influencing the level of jitter. I've been using the JTEST file which is designed to stimulate jitter in the SPDIF connection. Its basically a jitter torture test with a 11.025KHz main tone with a 228.6875Hz secondary tone at a level that modulates the LSB. By performing spectrum analysis of the output of the DAC playing the test file you get a measure of the jitter in the entire playback chain. As the DAC I'm using has a CS8412 reciever the jitter attenuation performed by the DAC is fairly limited and there is an intrinsic 200ps of jitter in the output master clock. I've posted these grabs before but for the purposes of illustration. These show the recorded output of the DAC displayed in the spectrum analyser of iZotope RX4. I've zoomed in on the base of the main 11025Hz tone to highlight the differences. The degree and height of the spread at the base of the main tone is related to the amplitude of low frequency jitter, and this seems to be particularly susceptible to PSU noise. This shows the Konnekt 8 powered from firewire -> DAC -> Konnekt 8 inputs While this is the same setup powered by a LPSU and the power and ground pins on the firewire taped over. As can be seen there is a clear reduction in the amount of spread at the base of the main tone, which suggests a low noise PSU gives a reduction in low frequency jitter, but in this case does not influence level of the side spurs. The main flaw with this test is that the LPSU will effect the ADC in the Konnekt8 as well as the SPDIF conversion so it is probably a case of double dipping. I'll use a battery powered digital recorder (Sound Devices SD722) for future tests to eliminate this variable.

Hi Jud, I'm lazy I use roomie remote + a global caché wifi -> IR interface to make the system manageable for my GF and I like the simplicity of being able to control things off a single app rather than having to use a stack of remotes and or rooting around with VNC. I'm willing to trade a few processes for this but it means one of "deal breaker" criteria of an audio player is that it must support Apple iTunes remote protocol and do gapless playback on ALAC. This is one of the key reasons I've been using PM and A+ in iTunes integration mode. It's just too nice being able to adjust the volume on the preamp using the volume control on the "remote" for iTunes. I'm a bit of a fan of R2R DAC's and balanced interconnects. My current DAC uses 4xPCM63P-Y in a balanced configuration -> zero feedback JFET I/V and a home-brew secondary PLL using a Tent Labs VCXO. It's jurassic technology, but very little of what I listen to is available in anything more than 16/44.1 so it does me for now. The fact that Miska's DAC is 100% reliant on his software makes it unusable for my needs. This site has a nice summary of the Soekris R2R DAC if you haven't seen anything about the design: https://hifiduino.wordpress.com/2014/10/12/r2r-for-the-rest-of-us/ Anyway this is getting way off topic....

Thanks Alex. I'm still running on the stock PSU. I've had peek at HQ but the lack of ALAC support and remote intergration are show stoppers for me. Next upgrade is probably the Soekris R2R DAC when that finally goes on sale. I'll get around to doing some tests with the JTEST files to see if I can pick up any difference between the players and optimisation levels. There are some interesting results of tests done with JTEST Archimago's Musings: MEASUREMENTS: Bit-Perfect Audiophile Music Players (Mac OS X). The most interesting thing is the comparison between Pure Music with Memory play on and off. Despite the author claiming that there is "no difference" the base of the main tone shows differences including additional spurs and spread in the "memory play off spectrum". This is indicative of changes in the level of jitter at the output of the DAC between the two settings. This is my comparison of the two Pure Music test images posted to the above site. You can see the difference with the additional jitter spur on the left of the main tone, and a "fattening" of the base on the right of the tone. So there are audible differences between memory play on and memory play off, and there are measurable differences in the JTEST spectrum analysis. The other tests also show differences in jitter spurs and noise floor, but this is all dismissed as "below threshold of audibility".

Hi Alex, A couple of things like com.apple.dock.extras and BKAgent caused the maxed out CPU usage problem, so I've had to keep them enabled. There is some low hanging fruit in terms of correcting for changed names of launchd .plists. I have only really focused on LaunchAgents and but disabled TimeMachine related LaunchDaemons etc and managed to trim down to 79/355 with screen sharing enabled and Stello U3 in place of the Konnekt 8, plus A+ integrated with iTunes and Activity Monitor. I had a bit of a listening sessions and I think at this level of trimming there is a noticeable improvement in SQ - what I think I was hearing was a wider soundstage and a bit more definition in imaging. As for the relative merit of the individual apps all I can say is they are all different! I'd been holding off on JRMC but I was quiet surprised that it sounded pretty good. I don't think it's up to the standard of Audirvana or even Pure Music, despite the fact that the presentation is superficially seductive. To my ear and in my system JRMC sounded impressive at first, but when I did some comparisons it didn't give the same sense of body and fullness as A+ or PM. One of the tracks I used to compare was Conceptions from 4 Hero's "Creating Patterns": https://www.youtube.com/watch?v=fC9V-emudLo The intro proved useful for picking out differences between the apps. PM has a dark presentation of the "room" surrounding the strings, and gives the bass and drums a lot of heft. JRMC has a lightweight presentation that sounds spacious but leaves you with a sense that the acoustic bass is quiet insubstantial. The same lightness seems pervade the entire spectrum, so the intro strings seem to lack the sense of "room" that PM and A+ give. On the other hand PM makes the reverb on one of the saxes in Miles Davis's So What almost too obvious to the point the it feels live it's been pasted into the track. A+ seems to strike a good balance between the two extremes, and still provides a fullness to the sound that was lacking in JRMC. FWIW My system is a bit of a witches brew of DIY gear: Audiovector Ki1 signature speakers, Hypex 2 x 180HG + HxR amp, Pass Clone Aleph P1.7 preamp and D1V3 DAC (loose clone of the Pass D1 with JFET I/V and buffer stages and Borbley SuperRegs integrated into the board.) Stello U3, and mid-2011 mac mini (with discrete graphics chip) 8Gb ram. cheers Paul

There is an interesting CL tool called powermetrics that gives quite a bit of information about CPU utilisation. It's intended for identifying energy consumption but seems potentially useful. As an exercise I decided to try out a comparison between PM2.0 and A+2.0 both with iTunes integration. Without optimisations: PM2.0 + iTunes: processor consumption was generally in the range of 7.3W, and system average frequency running at around 55% of nominal speed: 1350MHz A+2.0 + iTunes: processor consumption settled at around 4.9-5.0W with system average frequency running at 38.xx% of nominal or roughly 960Mhz A+ standalone: process consumption dropped to between 4.6-4.7W with system average frequency running at about 33.8% of nominal or 850Mz. With optimisations: PM2 + iTunes: processor comsumption varied between 7.35 -7.6W averaging 7.45W and system average frequency fluctuated between 52.9% (1322Mz) and 54% (1360Mhz). A+2.0 + iTunes: processor consumption settled at around 5.0-5.2W with system average frequency running at around 38.00% of nominal or roughly 950Mhz A+ standalone: processor consumption dropped to between 4.75 -4.85W with system average frequency running at about 33.5% of nominal or 835-840MHz. Not sure what is going on with the increase in processor power consumption with "optimised" OS. There are a lot of errors being thrown so I suspect this might be a contributing factor as energy consumption is tied to interrupts apparently. cheers Paul One further metric: JRMC running on stock Yosemite: 7.4 - 7.6W with System average frequency of about 53 - 54% or 1340-1360Mz.

I don't hear the benefits of the OS upgrades, and from what I've seen those who do are relatively few in number. TBH I think the optimisation process is massively over-rated once you get beyond the big ticket items like time machine and spotlight. For all the fuss about process counts you have to keep in mind that virtually every process listed in Activity Monitor is sleeping when not actively being used, so has zero impact on CPU usage. cheers Paul

It's not exactly negative experience , but there are a lot more change under the hood, and harbingers of more change to come. The who Launchctl process is being reworked and launchctl "unload" and "load" subcommands are now tagged as legacy. I'm sure it will be around for another few major releases but that indicates it will be removed at some point. DNS has been altered too. A group of what were individual processes have been rolled into a single process called discoveryd which runs at 19 threads on my Mac Mini. There is an increasing number of active processes that were originally iOS specific which points to the direction Apple are moving with OS X. So it's more of a challenge than anything else, and I doubt it is possible to get down to the same process and thread count as I was achieving under Mavericks. A laptop actually gives you an advantage in this case as you don't need to run networking, screen sharing etc. As I've posted earlier I've been able to achieve 50 process and 251 threads with PureMusic+ 2.0 and iTunes and Activity Viewer under Mavericks. CPU usage is a bit of a moving target and dependant on the CPU used in the model you are running, but while playing music I was seeing around 90% idle. Processes sleep when not actively being used so taking these metrics with the computer idling doesn't tell you much about how effective the optimisation is. I did a bit of work on culling Yosemite down yesterday and I currently have the system sitting on 87 processes and 372 threads with a bit of fat added for command line access. I'm tending to use Audirvana+ as I was having issues with gapless playback on Pure Music. One of the advantages is that both A+ and iTunes have significantly less impact on CPU usage than PM + iTunes - overall CPU usage drops from around 10% to 4% while playing music. Running A+ alone slices another 1% of the CPU usage but I'm willing to trade that for the ability to use Apple Remote functionality, and I hate the A+ library with a passion - seriously, it's 2014 not 1998 so why the sorry excuse for a library browser? SoundJamMP (circa 1998) cheers Paul

I've finally got Yosemite installed and had it running for a few weeks so thought it might be worth looking at the scripts again. Having had a look I am seriously tempted to go back to Mavericks for my audio OS. All Yosemite seems to bring to the table is tighter integration with iCloud and increased security. A few of the tweaks I'd made to disable XPC processes relating to iBooks and Dock extras needed to be removed as the OS runs at 40-50% logging errors. I'm not sure how much luck people have with the CAD script but after running my script on Yosemite and making a few modifications I'm still seeing 105 processes and 400+ threads. cheers Paul

Yes, it does improve the SPDIF output. I've done some testing on a Konnekt 8 with a Welborne Labs linear supply and there are measurable improvements over the same interface powered from Firewire. The Konnekt 8 is pretty clean with firewire powering but the LPSU does improve it further. This shows the spectrum analysis of a 16/44 JTEST.wav sent Mac -> Konnekt8 -> SPDIF -> D1V3 (Pass Labs D1 clone) -> Konnekt8 mic inputs. And this is same setup with Konnekt8 powered by LPSU... The LPSU is probably helping somewhat with the input/ADC on the Konnekt8, but you can see the effect on the spread at the base of the main tone. The height and width of the spread is related to low frequency jitter, so the LPSU is clearly improving this aspect of the SPDIF output. On the other hand there is virtually not difference in the jitter side spurs so the Konnekt8 isn't doing much to attenuate jitter on the SPDIF output. A Stello U3 is clearly better in terms of jitter attenuation, but not as effective as one might be inclined to believe after reading some of the audiophile press reviews. You can also see the Stello U3 has a significant amount of spread in the main tone. If your DAC has decent jitter attenuation you might be better off with the TC Konnekt 8/Live/Impact Twin + LSPU than a Stello U3. As an example, I've been experimenting with a home brew secondary PLL in my DAC and in conjunction with the Konnekt 8 its cleaner than the same DAC setup + Stello U3. Stello U3 + D1V3 +PLL/VCXO Jitter reduction Konnekt8 (FW powered) + D1V3 +PLL/VCXO Jitter reduction cheers Paul

That's roughly what I'm getting - 64-67ish depending on what I have enabled. I'd make the observation that the I'm being pretty selective in the non-system process that I disable. If you have a look in: ~/Library/LaunchAgents /Library/LaunchAgents /Library/LaunchDaemons (use Go to Folder in the Finders Go menu to access) you may well see additional plist files that you'd like to disable. These folders are used by third party software and on an "out of the box" OSX install they will be empty. The problem with just disabling everything in these folders is that sometimes software you need to run will add items to these folders - TC Electronics firewire drivers were the ones I needed to use. You can either modify the script yourself or post up the names of plists here with the folder they were found in and I'll add them to the correct spots in the script. cheers Paul

It shouldn't touch ethernet as that is a low level kernel function rather than something running out of a launch daemon. I have to admit I hadn't tested the script on OSX Server. There are so many extra process involved in running the server software that I uninstalled Server when I started messing with optimisation. As suggested earlier in the thread check the firewall is disabled as this may be an issue. cheers Paul

Attached is a reworked .command version of the script. This is "de-optimised" compared with the previous scripts. The script now checks the OS version before doing anything else and will currently exit if you are running anything except 10.9. The benefit of this is that when I start optimising Yosemite the optimisations can be split in to "core" and "version specific". I'll get around to incorporating 10.8 specifics at some stage. The other change is that there are now 2 levels of optimisation. The BASE optimisation is essentially the CAD LaunchAgents and Launch Daemons lists with corrections for difference in plist names between ML and Mavericks. The Additional level includes a small number of relatively safe optimisations, and disables Virtual Memory if you have more than 8Gb of RAM installed. Unzip and double click to run the script in terminal. cheers Paul opti_script_v1a.zip

Facts are slippery things... The 200ps jitter figure is only true if the recovered Master Clock (MCK) is used. So a DAC using the FSYNC clock from the 8412/4/6 will have an incoming jitter figure limited by the quality of the transport/cable/spdif implementation. This "trick" was used in the real world - for example Pass Labs D1 DAC utilised the CS8412 FSYNC clock, not the MCK.

Hi Uwe, I'm holding off Yosemite for the moment - until the first point release anyway. I'll look at updating once I do the upgrade. cheers Paul

Good result with the system culling. You could probably kill of firmwaresyncd but I'd keep it around so you can run after system updates. tccd is another candidate. It controls privacy access to address book/contacts etc. Sorry to hear the scripts didn't work for you. I have fairly vanilla installs of 10.9.5 on a 2009 Macbook Pro and mid-2011 Mac Mini and both boot using them, but it's difficult to account for all permutations. If you have trouble with booting it's worthwhile trying a verbose boot - command-v at startup. It might help identify where the boot is hanging up. cheers Paul