XXHighEnd

FYI:

I moved forward to Yosemite. Not entirely unexpected the NOS1 driver doesn't work anymore. I've re-installed the current driver in several ways but the NOS1 is not recognized.

Is the new driver Yosemite-proof?

Regards, Coen

Hi Coen - Yes. That is, if it works in the first place of course.
I was handed another attempt yesterday late afternoon, so this afternoon I am going to try that.

And I say it again (or maybe I did not say it at all) what a supersh*t this Apple environment is. YOU-DO-NOT-WANT-TO-KNOW. Those guys are just totally crazy.

And Coen, you may just have ran into an example of that and which is all what I am experiencing similarly; you installed a wrong driver (you stupid !) on a wrong OS and you most probably will not be able to ever get it working again. So it is about THAT.
And hey, did you see anything FAIL ? No no no, you see very green large OK marks. And now you are already stuck because of these OK marks and you won't know what you're at.

Anyway, this is how it's going on for myself for weeks now. Meanwhile I need to know as much about OSX as about Windows in order to get things right again. So FYI : What currently is going on is that any wrongly installed driver won't let itself over-write anymore (read : you can't uninstall it and you also can't install a new one while all says it's OK).
The uninstall can be done manually though (delete a couple of files) but it should go automatically.

Apple keeps on changing things and it is a complete hell. They just do what they like and leave it to poor guys like application developers and in this case driver developers.
When all this work has been done, the consumer is not supposed to see anything of this.

Nothing of the slightest kind happens ever to Windows.

Peter

Haha!

Now we're trading places: lost and frustrated developers instead of users!
Is there an OS where we can meet? Is the Linux environment even harder to manage or does it not have enough users?

Thanks anyway for the effort!

regards, Coen

Hello Peter

Thanks for working on this.

Are you doing all the programming yourself?

Regards, Michael

Michael - I wish I were. So this is part of the problem;
Obtaining a "license" for the things which need to be done here takes 6-8 weeks, and that is easily rejected. So I hope Apple reads this : because of this uncertanty "we" use licenses from someone else because otherwise it is undoable. "We" = a whole world. This is not even illegal but the "publisher" is not Phasure now and this may look strange. But it is what I chose for.
It is not really about the programming on the driver (which sure is what I do myself) but about generating the "build". And it is this part which all the time fails because of an Apple change in 10.10 with (as it looks) no downward compatibility. In itself such a thing happens more often, but in this case the install itself fails in a destructive way which can't be turned around. Or maybe now, because the guys helping me also need guessing while they can't try it themselves because all had to start with an install like Coen's (or my own) which needs to fail first in order to mimic the behavior.

More later today ...
Peter

Sorry to hear it is so difficult.

Thanks for the update.

Regards, Michael

Coen,

As it turns out (only now) the new driver does not work on 10.7. 10.8 should be OK but was not tested (anywhere). 10.9 and 10.10 has been tested but not by me because ... I'm on 10.7.

Can you please test this ASAP ?
I just sent you the driver (in 2.6.0 version as you will see it for the Mac).

Thanks a lot, also on behalf of others ...
Peter

I allready PMd Peter,

I did not try the 2.6.0 but the 2.7.0.
Installation run very fast. After the reboot the NOS1 was recognized and music playing within the minute!

I've let it play while messing around and noticed that there are tics with certain tracks with A+ and interruptions with a "krrr" sound associated with cursormovement. This is on battery mode. In "slow" filtermode (less cpu intensive), extreme priority and/or all other applications closed the ticks seem to remain. Not saying this IS about the driver but it could be.

regards, Coen

As a long time lurker on this forum I am motivated to register and respond that the driver version 2.7.0 that Peter sent me is working without any ticks or unexpected behaviour on my system...
OS X Yosemite + HQPlayer on Mid-2010 Mac Mini up-sampling to 384 with cpu load around 25% to Phasure NOS1a.

Regards, Peter C

Hello Fellow Mac Users

In my understanding with the drivers, you should be able to upsammple to the max. possible sample rate of 768kHz.
Can anybody confirm that this is either working in Audirvana or HQ Player?

Regards, Michael

Hey Coen,


Saw nothing. Not important, so just saying ...
But thank you for tryig ans super of course !


About the "krrr" sound ... try another USB port (on the Mini they are not the same electrically (and lousy to begin with). If that does not help check your grounding (:swoon::swoon: :)).
So "hearing your mouse" is always about grounding.

Regards,
Peter

Hi there Peter.
Thank you very much for lettings us know and trying.
And wasn't it about time ... :yes:

Best regards,
Peter

Mani,

I think you once told that you tried the NOS1 with HQPlayer on Windows and could use the Dual Wire option to output 705.6/768.
Did this really work ?

It seems that people can't get it to work with the Mac version of HQPlayer. And I can't test it.

Thanks,
Peter

Hey Peter, yep it definitely works. But you have to use WASAPI - ASIO only does single wire.

I haven't tried it for quite a while, but can do so easily if you'd like me to.

HTH.

Mani.

Wow, that's quick ! Thank you !


Oh, then maybe it doesn't work on the Mac ?

If anyone knows more ... ?

No need to re-try Mani.
Thank you ...

Peter

Previously, Jussi has always included 3 versions of HQPlayer in each download/install: Desktop, ASIO and NAA. The Desktop version is simply WASAPI. In both the ASIO and NAA versions, the '2-wire' checkbox in the settings area is grayed out. But I know Jussi has made some changes recently and there's only a single version of HQP now, with the option of selecting the output between WASAPI, ASIO and NAA. Perhaps the '2-wire' checkbox is no longer grayed out, giving the impression that it is active for ASIO and NAA? I don't know as I don't have the latest version of HQP. And of course, I'm only talking about the Windows version.

Mani.

I tried this on the Mac. After a lot of crashes I managed to get music in one channel. I tried a number of audio "software patch-panel" routings to no success. NOS1 768 switch made no difference.

Regards, Coen

Well, I've just downloaded and installed the latest version of HQP and I can't get it to work at all. 1-wire, 2-wire, no upsampling, upsampling, etc, etc. It just doesn't seem to work with the NOS1a. I'm sure the last time I tried it was before the NOS1a upgrade. Is there something up with the Windows NOS1a driver (or the XX engine that we're using with the NOS1a)?

Mani.

The only thing you can not do with another player for Windows (like HQP is one) is using 48 base material. OK, it will work but at the wrong speed. Otherwise ? nothing that I can think of.

One thing : I have noticed more regularly that WASAPI seems broken for the highest speed in XXHighEnd. But not even sure. So to be on the safe side I'd use 352.8 or 384) and that dual wire.
OK, this doesn't even make sense to myself.

Hey Coen, thanks !
Is that undistorted in itself ?

Peter

That was with the old driver/old OS and music was undistorted.

regards, Coen

Coen, I am sorry but I can not interpret your answer.

You told about the new driver outputting in the left channel only when 24/768 (705.6) is attempted with HQ;

I asked (or tried to) whether the sound is undistorted (so all OK but from one speaker only).

Thanks ...
Peter

Peter, I believe you can speed up the beta testing if some users are willing to disable Yosemite's "kernel extension signing" by storing the "kext-dev-mode=1" parameter in nvram as described in the first Step 5 here:
http://www.cindori.org/trim-enabler-and-yosemite/

Hi there Bob - thank you for this !

Peter

FYI:

I have a new driver available (if all is right for OSX8 and up) but I could not test it myself. Also, the couple who were actually waiting for this are all doing other things at this moment (Christmas Holidays and such), so ...

So if someone thinks he can use it, drop me an email.

This Mac driver is useful for two reasons :
1. Those who need it (for NOS1) on OSX10;
2. Those who own the NOS1a and like to switch base clock rates (44.1 vs 48).

Ad 2
Please notice : Only after someone has tried it, we know it works.

Peter

How new is this one?

I can check it out on i5 MBP 2013.

Regards, Coen

Hi Coen,

Not sure what you mean, unless I say 1 week and you understand that ...

Peter

Hi Peter,

That's more recent than the one I have. Please pm me.

Regards,Coen

at first: Happy new year to everyone!

The fruit of my endeavor:

I used A+ 1.5.10 on the MBP and I take it the driver should do the base clock changing, because I cannot find another way to do it.

Only with source material at base 48kHz I get music, with the 44.1KHz base A+ produces only static at higher sampling rates (2x etc). Pure NOS ("1xOS") it plays a little but fast forwards every now and then. Very strange behavior.

Oh and the base 44.1 material sampled to base 48 sounds to slow,

So either I don't know how to configure the system or it doesn't work.

regards, Coen

p.s. the driver version in the panel is 2.08.00.

Hi

Same findings as Coen.

This driver is not working at all.

44.1k playing too fast, and after a couple of seconds heavy dropouts.

48k playing with right speed but also after a couple of seconds, sound becomes totally distorted, dropouts etc.

Unfortunatly, I do not have the former driver version (2.7.0) anymore so for the moment I cannot play at all.

Regards, Michael

Hmm ... that is really odd. Sorry guys.
Michael, will send you the link to 2.7.0 again.

Peter

Guys,

I don't know what *you* are doing, but over here all works fine. Is this because the effort I needed to apply to get a machine to Yosemite, not knowing too much of any Mac, spending 3 hours or so to get some player running in there and hardly knowing what I am doing really ?

Please notice that I tried to get Audirvana+ running, but when I finally managed that with all kind of offline copy operations, it told me that it couldn't retrieve a trial license. Logic, because not connected to the internet and I thought what the heck. So installed HQPlayer of which "you" seem to tell that it doesn't do 768 etc., that leading to Miska thinking all sorts of driver stuff changed (which could not be confirmed by anyone), but here too, all just works. Or "too" ... I mean, when HQPlayer works fine, all works fine I suppose. And when not it's the other player or just you. Can't make anything else of it !

FYI, played with Poly-sinc filter and TDPF dither, both 44.1 and 48 based, each upsampled to either 768 or 705.6. Speeds are fine hence sampling rate and clock switching all works OK.

One thing with HQPlayer : It took me over 2 hours the other day (under Windows) to grasp what and what not to do in order to put through changes. So *that* can be your culprit easily, like always needing a restart of HQP to put changes through (Audio Midi changes at least, for the Mac).

For 16x upsampling set Audio Midi to Multichannel and Quadraphonic and no changes required further.

In HQP load a track and select that, now click stop because it always starts to play right away (grrr, who invented that). Now change the sampling rate you see in a combobox more up in the screen.
In settings of HQP you can activate 2-wire to allow for 705.6/768, and this is a typical change which first needs a restart of HQP. And then of course apply the other things because it doesn't remember much of what you set previously (because it depends on the track selected (OK, as it's told) and no tracks will be there after a restart). Notice : same thing when you started out with another device (not NOS1) - it requires a restart of HQP to detect the sampling rate possibilities.

When you now press Play you can see that in Audio Midi the sampling rate is changed indeed (when implied) and you can trust me that the speed is OK. If not you have other problems like not enough power in your Mac - whatever.
Also notice that with 2-wire, in Audio Midi you only see half the sampling rate as set in HQP. This is OK (just works like that, no worries and under Windows it's the same).

Lastly notice that I may sound sort of blaming, but the main issue will be that everything in a Mac is as stupid as hell. Everything. That's why it took me 3 hours in the first place, I guess.

Lastly, might it matter, this has been a fresh install of the driver for the machine involved. Can theoretically matter, although I really don't know f*ck about it.

Regards,
Peter

Hi Peter,

You must have had some 'beginners luck'  with the new driver install on OS-x 10.10. ;)

I restricted myself to Audirvana+ (1.5.10, not the new 2.x one) this time and that one is limited to 8x OS only.

I have a trial of HQplayer that I used previously out of curiosity. Changing settings is very user unfriendly, and it took me quite a while to get any sound out of it at all, but when it works it is ok for 8x OS. However in all my 16x attempts with it crashed after I ticked the two-wire checkbox.

I will try to remove the driver and reinstall it and try it on HQP with 16x. To be frank I don't think it will make any difference but I'm willing to give it another shot.

Finally there may be more than a driver needed. I had to update the Ifi driver form my nano-DSD as well as the nano firmware (!) to get it to work on Maverics. Some stupid USB compatibility thing that needed work on both ends of the interface. The Ifi now plays glitch and stutter free, even while working on the laptop and at 384KHz rate.

I guess there is commitment to the Mac platform and the driver may work flawlessly in the end, then the developer has still a driver update issue to solve.... :(

regards, Coen

Hi,

Ok checked all the "phasure" related files in the two "library" directories on the MBP disk. It turned out that despite two installs, the date associated with creation of the files was still the one of the PREVIOUS install. No clue what this means , but I moved them to the bin and did a fresh install. Now the files all have the date of the most recent dmg file.

To be more specific, the updated files are:
- the two .kext files
- the .plugin file
- the .plist file

Could not locate the exec file, but I presume that is the one that is updated or used anyway.

Results with
Audirwana+: no new results, as expected, unfortunately.

HQplayer 3.4.0: no crash anymore with 2-wire checkbox, but no 705/768 stereo sound with the recipe above, only left channel. (midi output:multichannel/Quadrophonic; "2 channel, 2 wire box checked). Nor is either 44.1 or 48 material running at the right speed, 44.1 to fast, 48 to slow (like with Audirwana +).

Sorry, can't make much more out of it, completely useless.

regards, Coen



!!!!! UPDATE !!!!!:

I noticed that HQ player has a newer version 3.6. Downloaded and started that and finally had STEREO playing at 705 and 768! Well sort of because the music periodically breaks up into music+a lot of static noise.

Unfortunately the to slow/to fast situation remains:

Nos1a clocks set by the driver at the wrong rate?

That would make real sense:
-  44.1xn output @48 NOS1a base clock = too fast + periodical buffer underflow,
-  48   xn output @44.1 NOS1a base clock = too slow + periodical buffer overflow.

Also this is not completely repeatable with A+, where -only- my 192 files play perfect with -only- 1x oversampling (OS).

Note that the "Phasure control panel" shows the correct rate values.

 

Coen, you might try the following Terminal command:
sudo nvram boot-args="dart=0x0 kext-dev-mode=1"

as discussed in posts 201 and 203 here:
http://www.computeraudiophile.com/f11-software/official-os-x-yosemite-thread-22030/index6.html#post368663

Thanks Bob,

This command is no solution for the to fast/to slow problem that was introduced by the latest driver.

Is it intended to prevent crashes or also drop-outs?

regards, Coen

It has prevented dropouts with certain audio device (DAC) drivers.  I do not know whether it will help with Peter's driver, but it is worth trying, and I do not believe it can make anything worse.

As stated in the ComputerAudiophile posting I referenced, you can revert to normal OS X defaults using:
sudo nvram -d boot-args

You must restart the Mac for any of these changes to take effect.

Another tip:
When installing an updated version of a device driver, the following command, followed by a restart, clears the cache to ensure that the new driver is used rather than the old driver:
sudo touch /System/Library/Extensions/

Really appreciate the help Bob.

Given promising signs from Peter and tips from Bob, I have tried to install driver 2.8.0 resulting in a complete fail.

Well, now I just get a mess…barely recognisable as music at either 16x or 8x (with Phasure switch in appropriate place and shutting down and restarting everything)!

Searched for hidden files and removed .kext before reinstalling; did not find .plist or .plugin…thought I looked in all the usual hiding spots.

I did get a song to play via A+ but it was wrong speed (44.1 file supposedly upsampled to 384 but playing slow); now hopeless with either HQP or A+.

Have used both Bob Sterns terminal command suggestions and restarted (again).

Have all problems: distortion, wrong speed, drop outs, stops altogether!

Given that that only thing I have not done is delete some of those hidden files, maybe that is it?

Tried reinstalling version 2.7.0…still f***ked up!  sh*t.  Not sure what I could be doing wrong.  I previously had no issues with 2.7.0 as long as everything was max upsampled to 384.

OK guys. First of all very sorry for your troubles; Of course I am totally in the blind myself (more than you if all is right) but let's try to get to the bottom of this.

First off, the 2.08 driver will be in

\System\Library\Extensions.
Phasure_CUSTOM_EXT.kext
Phasure.kext
both dated December 17, 2014.

If you don't have this, something else is wrong.
Somewhere will be a file for the Control Panel and one other program I think, but I regard this unimnportant (at least for now). If something is wrong or a re-install is required, these two files should be deleted (but which should go automatically !).

NOTICE :
What went bad with Apple in comparison with 10.8 is that the install moved (or seem to have - or was required to be) from
\Libray\Extension\
to
\System\Library\Extensions\

This is a bit vague, but if you find something in there for Phasure, it will not do a thing while you think it installed by viewing this.
But probably this will not have happened to you.

Also notice that this is to some degree about how to re-install the 2.07 version. Michael, did you manage to revert to this ? Is there a special note on this from you ?


Then to be sure, my Yosemite says it's 10.10. Not sure whether it would show 10.10.1 etc. when it would be that. This was downloaded/installed on December 30, 2014 and was upgraded from 10.8 (without intermediate steps). I recall that in parallel to this download (which I initiated on maybe December 10 or so) another download was auto-initiated on December 30 when I continued the download (I paused it this 20 days earler) which to me looked like an addition to 10.10 native. Not sure where to look what's really installed for updates.
The install itself was done without further internet "in the end", meaning that I didn't allow further iTunes etc. updates. Did not install Cloud stuff - and anything that I could avoid when asked for (so I didn't allow any further thing and then hooked it off the Internet).

Installs like A+ (which in the end failed - see previous post) and HQP were done without internet connection (moving around USB pens).

I hope this is a start ...
Peter

One more hint to drivers which won't install hence leave the old stuff be :

First off you won't notice this. The green OK tells you all is fine, while nothing happened (thank you Apple). One of the (totally stupid) reasons is this (and please correct when better data is available) :

The increment of a version number is tracked by OSX. This - and this seems to be new - means that no "newer" version like 2.0.1 can be installed over a 2.0.8 already running. Really so, and this is reason #1 as it seems to me that you can't revert (to 2.0.7.). But delete mentioned files and all looks to be good, while *still* something is in there knowing about this.
In the end I could not fully track this because these kind of issues I ran into on 10.7, at that time not knowing yet that things so much changed that 10.8 is required for minimum.

Side note : I can't upgrade my 10.7 to anywhere because of a perceived non-GUID partition I don't know anything about (that particular iMac was just bought running from an Apple Shop but with the notice that I installed Bootcam on it later).

Next thing we ran into is that no version can be above "99". So something like 2.102.1 can not exit. But of course the green OK is there as always.

This is all just side info and context for who-knows-what.

Peter

A question to those perceiving "wrong speed" :

Can I aussume that this is "wrong all over" ?
I mean, it is easy to interpret this (for me from your reporting and for you by not thinking somewhat longer) that you receive the speed from e.g. 48K as it is 44.1. So say 10% too slow.

But I don't believe this can happen, because this just works fine, and the slow down must be something else (like not enough juice). In the end I mean this :

If you can proove that this *is* the 10% difference, then all I can think of is that the driver did not install as it did over here and that you use something old after all. So notice : the 2.0.7 does NOT solve this issue (unintentionally). Still though you can make that manually right like this (HQP example) :

Assumed your NOS1a was left in 44.1 base state (say previously you played 44.1 material and all was fine and then you hook it up to Mac/2.0.8.
Now you play 48 based and perceive the wrong speed. But what you will have done also (most probably) is tell HQP to now output in 384 (opposed to 352.8 ). Only then the 48 based clock will be used (because 384 is 48 based). N.b.: Same with 768 and 705.6 with two-wire).

Now what I suggest is :
Whether you choose 384 (768) for output or 352.8 (705.6) - assumed you play 48 based material - your issue will be the same and report wrong speed. And so once again :

It is not so easy to understand how player like HQP operates, maybe espicially when used to XXHighEnd. So with the latter you can just say "upsample 8x (or 16)" and that's it. Very easy to detect the wrong speed because you can not *set* anything wrong. But for example, set HPQ to 352.8 output while meanwhile you change the base material from 44.1 to 48, changes ... *nothing*. Output is and stays 352.8. So if you now perceive a change in speed, blame HQP itself (but don't because it is fine) or blame something like not enough juice or whatever more that can be wrong. But never fool yourself by thinking that the clock requires switching because it just does not in this case.

Btw, if nothing changed, then A+ can explicitly set the 8x etc. So what I just said does not count for A+ (works the same as XXHighEnd) unless you denoted "maximum" (which would always be 384 and then again no clock will change, BUT it it would always be 48 based).

Still get it ?
Maybe not. Because when you hook up your NOS1 in the "always 384" situation (like latter about A+) then I can expect that nothing happens for sampling rate CHANGE because that it what's required to change the clocks in the NOS1a. Think like an event which requires to fire - the explicit change.


All this mst probably will not change much, but to me it is clear that this can all be the most confusing because you already assume it doesn't work anyway and now blame what you expect from this. And this is not so easy to interpret, as I now hopefully layed out.

Peter


PS: Avoid large buffering for A+ at first because to me it is 100% clear that you implicitly report about that part not working well ("works for a few seconds" etc.).

PPS: Pfff.

Ok, I realised that when I reported that driver 2.8.0 did not work, I only tried to send (to the DAC) material at 352 and 705 upsampled from 44.1 material in HQP.  The output contained lots of drop outs, noise and stops; barely recognisable as music much of the time.

I have since tried the same test but with HQP upsampling and AudiMidi set for 384 and 768 and find both work without any noise/ drop outs/ stops...except that it plays slow by ratio of 44.1/48.

With 2.7.0 I was able to get the timing of the music right only if I used material upsampled to 352.  384 was too slow by ratio of 44.1/48.  Neither 705 or 768 worked at all.

Does that shed any light?

Peter, I did not test this, but I am pretty sure this is WRONG procedure. It works the other way around !! And actually as I told, but possibly too much in between the lines :

1. Change the output rate in HQP (main screen, the rightmost combobox IIRC);
2. Observe (and nothing more) the samplig rate changing in Audio Midi automatically.

What you seem to do if I understand correctly, is after all these facts change the sampling rate in Autio Midi again. That's a guarantee for things not working ... (becasue it slaves to the audio player like HQP and it does that at changing the rate in the player (at least HQP) and NOT when you press play anymore).
So you destroyed it through the backdoor. Ehm, I hope !

This will be without much value (but it disturbs me as hell) :

You Mac guys always say that everything on a Mac is so intuitive. I tell you (ok, from my logic) : nothing is. NO-THING.

And sure I hope this topic in the end proves that.

No, I have misled you then.  I changed it only in HQP; the change is reflected in AudiMidi without me touching that directly.

I have check again and same situation...only touching upsample rate in HQP, which is changed automatically in AudioMidi.  705 does not work; 768 works but 10% slow.

What do you mean "does not work" ?

Please try explicitly and report :
16/44.1 file, output in HQP to 705.6 (2-wire active) : What do you perceive ?
(Switch#5 in NOS1a down)

OK, something else - and about not enough juice (perhap) :

Try to find a small track like 1 minute or so. This could matter. Maybe Beatles get you there easily (or close).

Exactly what I have been trying just as you specify..."does not work" means, drop outs, noise, stops completely for long periods (and I perceive voice sounds high pitched).

Then try 16/44.1 file, output in HQP to 768 (2-wire active); (Switch#5 in NOS1a down)...now plays without dropouts, noise, stops...but plays 10% slow but timing vs. stop watch.

All above change sample rate only in HQP.

Stoooooooooooooooooooooooooooooooooooooooop
and
F*****************************************CK

Because I too much believe what you guys are telling, I now found my own mistake. And you sure will believe how stupid I myself can be and how much I can waste my own time, including yours ...

Yesterday I did not feel like taking out my own NOS1a from the cabinet (want to preserve the perfect SQ I have these days) and grabbed another one. And what did I do ?
I took one which is not upgraded to the "a" yet.
Very nice, but in there no special clock-change treatment is required. So that always works (about the wrong speed).

How do you say "I apologise" ?

Now trying with an "a" ...

This has brought me so many surprises that I don't know where to begin to make logic out of it ...

Generally, indeed, no output of 705.6 (16x) plays without super distortion. 8x 2-wire same thing. 8x 1-wire same thing.

But something new (meaning you guys did not report this) : No speed is correct anywhere. It is or too slow or too high. Counts for the 44.1 based (as long as I can see the signal) and counts for 48 just the same.
I can't even find the logic in when too high or when too low, but what I seem to have seen of it, it's the difference between the output rates (so input (file) is not important for this.

Now very coincidentally I am super glad I saw this working yesterday with the "non-a" because otherwise for 100% sure I would have blamed the player.

It will be outside of your scope, but to me it feels that the sampling rate is changed all right, but that next internally something else is reported to the OS. Say like : first tell Audio Midi about the sampling rate, and only next do it for real and then something back fires.
Do notice that I did this for Windows myself and that this works fine to next tell a couple of other guys to apply it like this for Apple, and assumed they did that, this now does not work at all.

Also, I will be mad most probably, but while I told earlier that I saw the sampling rate change in Audio Midi after changing it in HQP, I now only see it change in Audio Midi when I press Play. Was I wrong in observing yesterday ? maybe. But I sure see how such a change relates to what I now see happening.

Maybe I need to apply some more checks ...

Yes I was; just re-checked it with the non-a.

I was wrong. The music sounded normal, but compared to the laptop's audio out it is definitely to slow.

I'm glad that our findings are repeated by Peter.

regards, Coen

But Coen, this still doesn't tell me about too slow in absolute sense. Probably you are saying this but can you confirm ?

Peter

When you replace an extension by simple Finder copy (drag-and-drop) rather than running the Apple Installer program, I do not believe OS X cares whether the new extension is a higher or lower version number.  (Although I have to admit that I am not using Yosemite.) 

The usual cause of an extension update being ignored is that the old extension remains in cache.  OS X does not notice that you installed a different version of an extension if you merely copied it in the Finder instead of using the Apple Installer program.

The solution is to clear the extensions cache in one of two ways:

1. The "touch" command in my previous reply #36.  However, I made a mistake: I specified the Extensions folder for OS X 10.8 and earlier, not the new one for Mavericks and Yosemite.  The "touch" command for the latter is:
sudo touch /Library/Extensions/

2. A completely foolproof method, although extra steps, is to restart the Mac in "Safe" mode by holding down the Shift key after you hear the startup chime until you see a horizontal thermometer icon (representing the progress of the fsck operation).  Login in Safe mode, then restart again normally.



GUID versus AFS is a property of the entire hard drive, not of an individual partition.  To convert a drive to GUID you must completely erase the drive, recreate the desired partitions, then restore the data from a backup.  Instructions at:

http://support.apple.com/HT201723
or
http://bombich.com/kb/ccc4/preparing-your-backup-disk-backup-os-x

And again Thank You Bob. Not sure where your help in here springs from, but for me as a Mac NooB it is really really appreciated.

The GUID thing ... yeah, that kind of answers I read everywhere. Assuming you have that Backup ready etc.
But what I never read is how the heck such a thing can emerge. So again, I didn't partition that disk and if I would have it would have been GUID in the first place.

Might you like to provide one more little sentense of help :
What is reliable for making a backup of an iMac ? One which was little later provided with Bootcamp ? One which extends the Bootcamp partition with a FAT USB disk (which requires tweaks under Windows I could do (and are not readily available) but which makes me reluctant to say the least to go the backup and restore route in the first place).

Thank you Bob ...
Peter

1. Although I don't own a NOS1a, it does greatly interest me as a clever design that I'd like to audition eventually.

2. I've been a Mac user for 24 years, and I've developed AppleScripts, etc for managing my music library, so I like to do what I can to facilitate the Mac as a platform for computer audio.



Bombich "Carbon Copy Cloner" is the backup program I use.  It is the highest regarded program for carefully preserving all the hidden files, permissions, Bootcamp partition, recovery partition, etc.  It has a fully functioning 30-day free trial.

http://bombich.com

The help in the Help menu is the same as the online help, so it probably is easier to view the instructions online.  I believe there are instructions in Nederlandse, too.

http://bombich.com/kb/ccc4/how-set-up-your-first-backup

That is super Bob. Thanks a lot.

I'd estimate about 10% which makes perfect sense: 48khz consistently too slow and 44.1khz consistently to fast.

Iow 48 played back with 44.1 clock and 44.1 played back with 48 clock. Clocks differ in the order of 10%.

Regards, Coen

Hey Coen,

Yes, I have been thinking about something like that. And could well be a most logical explanation of something which consistently goes wrong; It would only be a matter of some programmer switching around the code concerned (have the If / Else (content) the other way around).

Now I am going to make a few phone calls ...

Thanks !
Peter

To those concerned :

I just sent an email with a new driver and which works. Ehm if I tested all decently this time. ;)

Small problem, this one too has version 2.0.8. But per instructions in the email you will be fine.

Peter

I am actually waiting for some feedback ...
Not that you need to try when not intended in the first place, but I assume someone did ?

All worked fine on my laptop. That is no problems with switching between base 44k1 and 48k frequencies on Audirvana +. All played!

Still there are some ticks and interruptions at 8x rate. Maybe my laptop (i5 based) is too slow. Different buffer sizes do not matter.

Regards, Coe

Hey Coe(n),


How would you describe this (better) ? When, frequency of it and such. If you have some spare time of course.

Thanks !!
Peter

Hi Peter,

The ticks are only noticable with classical music and not on very quiet passages. I guess in the order of every 4-10 seconds. Furthermore the trackpad gets priority over the music playing, when moving the cursor the music immediately OR after a few seconds breaks up with  static for a second and continues normally. It sounds like "krr krr krr..." and the music runs in its normal pace through this interruption.
 Also when the os locks into the start screen or occasionally runs a prioritised process the break up occurs. The priority setting in audirvana plus does not really make a difference. Closing all programs including the wifi connectivity seems to alliviate the problem a little, that is there is a less direct response to the moving of the cursor.

HQ player exhibits the same behaviour yet is worse. There is a total breakdown of the music for a couple of seconds before the music restores.

At best I can listen a short music track without interruptions with audirvana plus.

Regards, Coen

Thank you Coen.

Is this happening "as easily" at a lower output rate ? ( like 352.8 )
Just trying to find out whether it can be a "not enough juice" issue.

Also, how bearable is this "static" ? So notice that static as such is window breaking. "Krrr krrr" does not seem to be like that. I'm asking because I like to observe myself by listening (instead of looking through analysers) but since I don't have a pre-amp or other means of analogue attenuation ... I like to keep my windows in.

Peter

Hi Peter,

Audirvana plus ends at 352.8/384 so that's what I'm talking about. Same problems with 176,4/192 (4x), but 2x seems to work better (like 192 source material x2 = 384) with less interruptions.

HQ player break up becomes less severe at lower rates but remains at all sampling rates.

I will have to check 1x for you.

The break up is quite disturbing in all cases. Read krr krr krr as broken music (lots of static) with silence in between. The static part seems to have a rhythm to it that is unique for Audirvana plus. With HQ player the sound 'just' collapses in to noise and finally silence to recover via noise into normal music again.

regards, Coen

Thank you very much Coen. And really no need to try 1x.

Peter

Hi Peter,

I have now used Yosemite driver 2.08a with complete success.  I have played using HQPlayer at 768 and 705 (44.1 material upsampled by HQP) and both play at correct speed (by timer) with no sound issues at all.

Thanks for resolving this from my perspective.

Regards, Peter C

Hi there Peter,

All I personally want to say and especially to you : and it was about time !

This has been the siingle occasion that I recall that I (Phasure for that matter) was dependend on a third-party and apparently have been unable to speed up things. And if I would have been you I would have gone fairly mad and angry. I mean, 8 months ??

So thank you very much for your great patience, Peter. And for your help.

Kind regards,
Peter