Ha ! just another combination which wasn't tested. But looking at the data ... indeed it is wrong. Half of it belongs to 96000, and the other half to 88200.

Sorry, and thanks !
Peter

I just downloaded the two available DXD tracks ... pom-pom-pom ...

Now it's only a matter of building a DAC around them.
                                                 

It doesn't look like it so far. But thanks for pointing it out.

It is up to Elias (et al) to respond here (which I would do soon ).

Ah ! That saves me a download. In fact I knew that, but forgot about it. Indeed, en e.g. english version won't install upon a dutch (etc.).

Btw, what I hope most to be solved :

a. The kind of random behaviour at falling asleep, followed by a rather normal boot at wakeup;
b. The sometimes ridiculeous harddisk access without apparent reason (lsass but can be caused by other things as well (not that I know which));
c. The stupid 30 sec. wait time at creating / renaming directories (which actually is not true, because the actual job is done immediately). Btw, not everybody experiences this, and I too didn't have this for the first six months (never installed any patches).

Thank you DJ.

I'd love to Edward, if it already were from preventing you all a mistake. But ... no time currently.
Working hard on the "preprocessing" thing (as well as your pops and things), and I don't think SP1 should preveil.

But within the week I should be able to.

Peter

My experience :

Once you can discern technical aspects, like the tout bass, and you are able to keep it in memory once you heard it from your system, it can be layed aside for later. As I said "from your system" is important, because your system can (no, will) unveil those separated technicalities, and all have one best setting : your reference for that part.
All you need to do now is unite those separate best references into one system.
Recognizing what causes what is obviously very helpful in achieving this.

Hey Andrey,

Not that I could have made that up myself, but now knowing it, to me it seems a kind of logic that that influences sound. But, thinking of what will be happening in there, I can only say that if it indeed does change sound, it seems like a "bug" to me.
Think of something checking (right in the middle of sound playing) whether another (application) wants to come in, which it should do when Exclusive Mode applications have priority. BUT, this should count for Shared Mode apps, and not for the Exclusive Mode apps.
It is my conclusion that now you should be able to interrupt Exclusive Mode apps (hence XX playing) with some other sound.

a. I can be wrong on this;
b. If not, this doesn't seem right to me

The latter because I'd say that this should be about the start of producing Exclusive Mode sound which now won't kill a Shared Mode sound. Not the other way around, that an Exclusive Mode sound can be killed by a Shared Mode sound. But try it, I think it does with that checkbox unchecked.

Oh. Maybe I didn't expect that. But still I think it is so that the OS responds to XX to give it priority (so to speak), similar to the services shut down (I know, that only happens with the prio settings). When it happens with me, it is always at the same time other things start falling over.

But as said, unless it is repeatable at will (!).
Peter

The ChangeWP error is rather normal (related to priority settings) unless you can repeat this over and over.

The Crack Detect "detection" might be a too critical setting by me. What album/track was that ?

Hi Frank,

Where did you get that from ?
Wasn't this Engine#1 (or #2) only ?

And otherwise, wherever you found that, couldn't that have been the "will not be bit perfect" situation ? (hence Shared Mode only).
Note that Shared Mode (not bit perfect) is not supported anymore ...

Thanks,
Peter

I'm not sure what your question is about ?
I meant synchronous to the sense of "no real buffer". Think a bit of how XX plays, looked from the HDD side. You could call this A-synchronous to the largest degree.

?

First of all you will have seen this : Re: Benchmark DAC1 USB;

Note that the 24 bit stuff is all in there by now, so that is not it.
The Benchmark is advertised to be compatible with Vista. I think : it is not, and I estimate it is caused by this :

AFAIK the Benchmark uses a special application of the legacy (MS) USB driver. It think it is even advertised that it can do 24/96 over USB without needing a special driver which normally is the case. Mind you, they say.

I think (!!) I read somewhere the other day that they applied a synchronous application, which is not the most usual. I won't say that by this means they avoided a difficult signed driver route (if that would go through at all), but anyway it doesn't work under Vista WASAPI Exclusive Mode, which IMHO is logic.

Besides that I can be off in my perception on matters, it is not up to me to decide (or know) whether indeed this is related to "not Vista compatibe" or Vista WASAPI not being compatible to MS itself. I think we all know how many problems I have with it myself and on which topics I can point out that Vista flaws on this matter. But then again, I think it is just logic that this won't work.

You can point a Benchmark technician to here if you want.
Sorry.

Peter

Now what ...

I'll dive into the Benchmark specs and see what I can find there ...
Doesn't look good though.

Now you're set the Primary Device properly (and assuming before this wasn't so !), what does this say now ?
Please copy the resuly in here !

Peter