Thank you. I am far from satisfied with this myself, so yesterday as well as today I tried to create some analysis code using Shared Mode. Had to give up because nothing useful came from it (as it didn't two years ago, but I thought maybe I'd know more about it by now ).
Sorry.

To me it somehow doesn't feel right. Q1 is just working and doing a kind of certain job. Now, newcomers don't know this. So what will happen ? they will slide Q1 along with the others. Q2-Q5 so far don't make much sense. Q1 does.

Ok, dove into it, and I don't think I can let stand what I said in above quote. Or anyway it has to be looked at differently. I'll try ...

1. The 24 bit thing (USB 2.0 audio officially NOT supproting that) is still true.

2. The 24 bit implied connecttion I talked about earlier would exist between the upsampler and the DAC.

3. We must wonder what is reporting to Vista here, the DAC or the upsampler ? I'd say the latter.

4. The specs of the upsampler talk about an asynchronous connection. This would be the Empirical way I talked about. Not 100% sure, but near.

5. The dCS specs do not explitly talk about 16 bits as being an input possibility. It says "up to 24 bits". Almost the same, but be alarmed here.

6. As far as I know, Legacy USB (meaning, what Vista (et al) support officially for USB audio, with MS drivers) should show as a Loudspeaker Device ("USB Audio") in the device list.

7. My earlier expression on upsapling requiering more than 16 bits (hence 24) still stands, but I don't think it applies here. It would if your DAC would be the reporting device, but I thing the upsampler is.

Ok. It may come down to the latter. I assume an Empirical device does not show like that. But I don't know actually. If at your side it does not show as a Loudspeaker Device, concider it proven that you're not using an USB Audio connection, but a USB data connection which "asynchronous" (dCS specs) suggests.

Btw, might you want to dive into these matters yourself, there have been discussions on the net (IIRC at head-fi) between Steve N. and Gordon J.R.. This is exactly about these matters, where Wavelength also uses an asynchronous connection but in the official way. This comes down to Empirical accepting 24 bit input only and Wavelength accepting 16 bits as well. For Empirical this means that the PC has to uprate to 24 bits first before their DAC (and OffRamp etc.) can be used.
For fun you might examine the specs on Empirical devices, where it doesn't say anywhere that 24 bit input is a must, but the stories about uprating to 24 bits first is way better are all over. Showing the real truth may be too hard, whatever. That is why I said "be alarmed".

The sad point is, that feeding such a device with 24 bits and be done with it, is not enough. Vista WASAPI just reports no DAC to be found when it doesn't comply to the Bill Gates standards, and then you're done.
This is again more complicated than you might think, because one of the parts of WASAPI is Shared Mode, and in Shared Mode your DAC (or upsampler) most probably will be found, because WASAPI will try other modes, may find a 24 bit device DAC and then tells the audio chain in Vista to resample to that (bit)rate from there on. And this is exactly what you do not want (not because I say so, but because of your initial question). That won't be a bit perfect connection ...

Then, as said before, XX eliminated the Shared Mode connection, because people wouldn't know what they listen to, and XX is there for the (intended) best SQ only. So why not eliminate Shared Mode ? the downside is obviously : if your DAC (upsampler) now doesn't talk to Vista in that one and only way it wants (which would be so in Exclusive Mode) you're over and done.


On another matter ... what is this about your Matlab program ? I mean, could it be beneficial here somehow ? On one side you seem to say "I can see everything through that program" (so can you ?) and on the other side you asked your initial question (implying that you at least can't see "that").


Maybe superfluously by now : In WASAPI Exclusive Mode Vista won't resample anything, won't add dither, nothing. It leaves the stream untouched. The problem left is that you must force Exclusive Mode to indeed be active, what a normal WASAPI implementation doesn't do. For example XMPlay does not as soon as it doesn't understand some little thing (about the asked for connection), let alone when the DAC really doesn't support what is asked from it. For e.g. Foobar I could not prove that, but then my DAC is just normal enough to get accepted by normal means. So that proof doesn't say much.

Well, I hope this at least is informative in some way to you.
Peter

No. You can't upsample without an additional bit per magnitude of 2. This has nothing to do with dither (and dither is not in order at upsampling).

I will move the Q1 slider back to where it was ...

Of course I can't know what your application is checking (and how, meaning at the exact right point in the chain), but the bit depth conversion (by Vista if it "needs" it) counts the same as the SR conversion.
If you want to check something, the only thing you really need to check is whether USB 2.0 specs allow more than 16 bits.

For example, Empirical Audio doesn't play either. Why ? ... their DACs accepts 24 bits only, and they tricked the USB specs coming down to not audio passing USB, but just data. No tricks really, but just smart. But Windows Audio doesn't dig it, no matter USB is suffidiently capable of it (I think to even 192KHz).

But this is all a bit premature. I will check out your upsampler and DAC.
Btw, please note this "DAC Test" is just Windows (Vista) reporting here. If that says "I can't", XX can't. I just can't help that. At least not when you disallow resampling of any kind, which XX just doesn't for the good sake. WASAPI Shared Mode is another matter, but that just allows this resampling. And I eliminated that "feature". Again for the good cause. Well, you know ...

It is not that difficult. You asked about Vista resampling etc. ... Vista (or Windows) supports 16/96 max over USB for audio. Any propriatary means may support more, but Vista WASAPI won't understand that. Nothing to do about it.
Note that I'm a bit speculative because "upsampling" as you say, needs 17 bits at least when the source is 16 bits. If the upsampling is not done right, 16 bits "suffice". But XX uses 17 bits (for 88.2) or 18 (for 176.4). And USB doesn't take that.
Note that Vista (when allowed, which XX does not) will resample to the available output rate. So, you may think you are playing 24/88.2 while actually this is 16/88.2. It may be hard to prove for you (or me for that matter), but theories of operation (legacy USB) says so.

It's all not that easy. I will sort out the dCS with the Paganini combo for you. Ok (for now) ?
Peter

Sure.


Oficially this is not possible. When done right, it would imply a 24bit USB connection. Can't be over USB ... officially (!). And Vista WASAPI needs official stuff.

I didn't get what your DAC is. Maybe it's important, maybe not ...

Although I can't get it from this text, there *is* something wrong with the cursor position at bringing up XXHighEnd again. At least for WAV files ...

The thing about the disappearing controls is solved and will be in the next upgrade. For the other things I really need you.
(but trust me, this must be about some very strange (font ?) setting you applied yourself somewhere. *Or* a special hocus pocus trick you apply to get the lot in that stage. )

Peter

Never mind this. I tried it yesterday, it was designed like it, but today at working on your problem of the disappearing controls at the bottom, somehow it doesn't work anymore. If you see the initial size (like after an upgrade) come up after this procedure, please send the screencopy indeed. But if not, never mind.

Note that the notch buttons should stay above the slider (which is only one thing I see wrong at your screen copy). If you can tell me how you do it that they move to the left of the slider, or when that happens ... please let me know.

Peter

Firstly, Engine#3 should just run in demo mode as well. Next what I described earlier (about sample rate conversions) just applies.

So the question is, why can't you run Engine#3 ?
What DAC do you have ?


I don't recognize the latter, unless you have Unattended ticked ... or try it with Engine#1 or #2. The DAC test is not fore those engines, and I actually never tried it. So if you did not try the DAC test for Engine#3, please try that (and load a 16/44.1 WAV file to play !).


I'm sorry that I overlooked that question. So, the demo version doesn't hold you back of anything ! (except playtime of on average 30 minutes per session (per startup of XXHighEnd)) and the output in the Library Area is limited to 100.

Please let me know what comes from this, and don't forget to tell what DAC you use.

No clue Leif. And not the experience either (I started a thread about this the other day).
But if you follow this How to delete a misbehaving ConfigFile and then mainly the part about just deleting such a Config file because of which XX again will start the question "Reload old settings" where you should answer NO at problems ... it will solve it most probably.

On a sidenote, this is standard Windows stuff, while I can do it explicitly myself just the same. In a next version the explicit thing will be in there. Seems a lot better (under control) to me.

Peter

From here : http://www.phasure.com/index.php?topic=717.msg5144#msg5144

Link to FileMail : http://www.filemail.com/default.aspx

Edit : Send the e.m. to sales at phasure com.

Actually it seems a good idea, no, a very good idea to use this for files not playing. It avoids cumbersome uploads to some place you must arrange for (when you don't have it), and for me it is the most easy (to get the file) as well.

Of course this officially is not allowed. But as I have said more often, blame me if something goes wrong. It is for a good cause, and a kind of normal operation. But only send files which don't want to play, and don't do it for fun or "listen how nice" reasons.
Also, don't convert the file to a compressed format, because it may undo the actual problem. And for sure don't cut it !

Lastly, try to keep in mind the source. If you can already sense the source is not trustworthy or something may have happened to the file otherwise, then please don't bother. This should be for the general cause.

Peter