Just some background on "non oversampling" (NOS) for those interested :

For me, unlike the first explicit provocer of it (Peter Qvortrup working for Audio Note) it is all about the squariness of waves. In music "square waves" exist all over, and if it isn't a synthesizer which can exhibit them as exact as can be (when no analogue devices where in the mix at recording), it is the coincidence of matters. An example of the latter in nature is thunder, which can be visualised by looking at the front of a surf water wave. And, while thunder is an example of the large level (think bass like) of squarish waves, instruments like a trumpet exhibit them at a more detailed level (higher frequencies). A tick on something like the edge of a snare or tom drum would be another (kind of) example, where the "square" exposes as a very fast (read : steep) transient.
At least in 44K1 sampled WAV data, transients exist ranging easily over 2/3 of the total voltage range, meaning that the voltage (for a 2V RMS output DAC) will change from e.g. -1.3V to +1.3V in one go ! So, in analogue form this cannot exist, because it would imply an inifitly fast rise time, but with 44K100 samples per second there's just no more "resolution" to catch the steps which may be there in (analogue) reality.
Note that with e.g. 176K400 samples per second there's 4 times more room for in between voltage steps, and a transient which is captured at 44K100 exposing one go, could show 4 steps at 176K400. Or still one, because the sampling rate is way way too low to mimic analogue.

Above I mixed two principles :
1. When a steep transient (or square sound) is really there, it should be expressed like that (first part of the above);
2. When a not so steep transient (or less square sound) is there in reality, it should not be expressed more square than reality was (second part of the above).

The second part is theoretically solved by a higher sample rate;
The first part is solved by just not rounding the squares.

The story becomes confusing, knowing that the first part will be emulated (!!) by oversampling. Note that oversampling as such, is nothing else than adding interpolated samples which are not real, but do round squares which were not perfectly square in the first place. In order to understand this principe, do this :

Draw a square 2d wave with the corners not being 90 degrees exactly. This mimics what happens in sound. Those corners must be drawn in digital steps and not in an analogue round fashion. The steps you draw are the samples take.
Now adjust thee drawing, by interpolating the steps with a factor of 2. Thus, each step becomes 2 steps. This must be done at the outside bondaries of where the rounding of the corners started. Thus, looking upwards, the rounding goes downwards. And, looking sideways (the top of the wave) the rounding goes sideways.
After this one step of interpolation, you can already see that at doing it again, the square wave becomes more and more rounded. Do this an infinit number of times, and a pure sine will be left !

The latter is what this is all about : oversampling DACs make sines out of original squares, and the sound is destroyed. Oh, it will be less harsh because of less squares, but "harsh" is relative, and when a trumpet shows the "harshness" of just that instrument, it should stay like that.

It is obvious that this all can be related to transients, and that steep transients will become less steep, and dynamics will be destroyed.
Whether we talk about squares as such or about dynamics, both are the exact same subject.

As a side note, keep in mind that when an exact square is fed to the DAC, oversampling doesn't matter a thing, because there will be no steps to interpolate (draw an exact square wave now, and try !).

When you understand the above, you will see why some people like oversampling DACs and others like non oversampling DACs;
Both contribute to something which could be worked out for the better, but when the oversamplig DAC works out for the better, this can only be because of too few samples in the data. With this I refer to the exmple of a transient being recorded too steeply, because there was no room to have more steps, those steps always being there in (analogue) reality. Thus, the higher sample rate allows for those steps which are better for theory on one side, but since the steps are no reality at all (the real steps were different), it works out worse at the same time.

Now here is the important part :
An oversampling DAC creates less reality because a too steeply captured transient will be flattened in an unrealistic way;
An oversampling DAC creates better reality because a too steeply captured transient, which is unrealistic by itself, will be flattened.

Got this ?
There will be no scientific answer to which of each "features" works out for the better, and both have an unreal result.
BUT :
There's also the matter of the real transients and squares which are reality from the start, and the oversampling DAC will get those out of the way just the same ! And thus :
The "feature" of the non oversampling DAC to at least pertain those transients and squares comes out of the equation as a positive.
And thus all 'n all the non oversampling DAC wins with 2-1.

There is quite some more to it, like oversampling shifting the nyquist frequency and therefore requiering less filtering, and for example of 352K800 it is said that just no filtering is needed at all. 44K100 just officially needs the filtering, which will operate in the audible domain.
The NOS filterless DAC just doesn't do that, and where filtering by itself will again destroy sound, the artifacts (if audible at all) from "aliasing" are taken for granted.
Again, "if audible at all", while at the same time synthesizer music is completely destroyed by oversampling. And this is audible for everyone.


Having said this all, the phenomenon "oversampling" needs some additional clarification;

An oversampling DAC, in 95% of cases is so, because it can't operate without it. The sigma-delta DACs are the example, with DSD (= SACD) in thee same line of working.
These 1 bit principles can operate only by heavy oversampling, meaning 256 times or more, up to MHz's.

The other 5% of cases, are about multi bit DACs which just do not need the oversampling in order to operate, but, it is done anyway for the reasons of shifting the nyquist frequency as briefly referenced to above, and besides that will need filtering which is always needed just *because* of the oversampling. In this case we talk about oversampling to e.g. 176K400 which is 4 times only. Note though that 176K400 actually is a strange number, and 192K is more normal, but since 192K can't be divided by 44K100, first a common denominator has to be found, and from there on heavy oversampling (underway) emerges again.

Although the definitions do not exist explicitly, one could say the "oversampling" is the heavy kind, here posed as a pure negative, while "upsampling" is going from e.g. 44K100 to 176K400 directly.


Lastly, and to get a bit from the abouts, at 44K100 sampling rate, a 22050Hz pure sine is represented as a pure square. There's just no more (sample) room to make it less than pure square. Similarly, a 11025Hz pure sine is represented as a square built from 2 steps. This is just audible, knowing that squares produce a ton of harmonics.
Now, upsample this 1 time, and the anomaly (for what it's worth) at the very audible 11025 is shifted to 22050 which is not audible (for most).
This is why heavy "oversampling" is beneficial by itself, because it shifts the anomaly into the inaudible area. But keep in mind : in a fake fashion.

All together you may get the grasp of the importance of a 192K non oversapling DAC, meaning :
When 192K native material is played, the anomalies have been shifted "over 4 times better" into the inaudible area anyway (but now with real samples !), which makes non oversampling "over 4 times more legit".

Peter

Hahaha, although you can very well be right on this, I have lost all my references.
Must learn again to listen to music too. I mean, typical lady jazz singers like Diana Krall or Barb Jungr didn't do all that much to me before. But now I just can't switch them off because of those basses used so profoundly. I said "used", and although Diana Krall rather heavily "used" it before, it now merely carries the music. But hey, isn't that always when such a bass is used ? well, maybe it wasn't through loudspeakers ...

The interest for (and of) the bass makes it a very tough job to listen to the other elements.

Anyway, the "ticks" as decribed earlier are completely solved now, and also I have a version of which I'm sure it sounds different. I must leave it to you guys though to interpret it.
Later today ...

Found it indeed. Solved it for myself, although not yet in the way it should for general purpose.

Uhmm ... But I assume that you downloaded XXHighEnd earlier ??

Anyway, you can do that on the "Download Area and Release Notes" board. For the latest version this would be : http://www.phasure.com/index.php?topic=623.0 and the zip to download is always at the very bottom of such a topic.

In XXHighEnd itself there's an Undemo tab, and in there is a PayPal button. That should do it !
You will receive an email instantly (but finish the few forms that come by after pressing the PayPal button), and that email contains the Activation Code that can be stuffed in the field under the PayPal button.

If you have any problems during the process, please let me know !
Peter

... Ok, apparantly I must dive into this. My, say, personal problem is that I derive much from the movie world, where getting audio over HDMI seems to be a tough job, and no one rule seems to exist (mind you, this is related to multi channel vs. 2 channel (where things *do* work) but in relation to AC3 and DTS *and* that 2 channel is not an option there obviously.

I could also say : do you know (definetely !) about a soundcard with HDMI input, which ... well, just works. From what output ? ahh, I don't know, because where is the CDPlayer with HDMI output ? and would there even be a reason for it ?

Right now two external DACs spring to my mind which officially support DSD meant to be read from files (computers), and both live in the recording world only (no, I didn't say Pro world !). So, an example is DXD (which is 352800) which nowadays often is used for mastering DSD. Also it goes the other way around : DXD can be used to edit DSD (DSD can't be edited, or it is too cumbersome to do it).
From this, I am fairly sure (but not 100%) that where DSD is converted to PCM without any losses, it would be 352800 PCM. Now, you might have a DAC that can do it (but you won't), but now where is the soundcard to pass it through ?

If I keep on typing, I just as well might find the solution automatically, but I only wanted to indicate this is all not so easy (at all).

Note that many DAC chips (!) are able to receive DSD, just because they're delta sigma, and because of the high oversampling rates needed for that principle, it's relatively easy to support DSD as well. This does not mean that "we" can use such chips for SACD material, which for 100% sure won't be playable from within a PC anyway (although mr. Putzeys created one in private). Thus, those chips are meant for being in SACD players ...

If you are looking for an external DAC being able to play the contents of e.g. your Oppo, you must catch the DSD stream (I think several external DACs exist with DSD input, just like I could provide it with the ESS Sabre).
If you can only catch the PCM stream it should not be downsampled, and if I'm well informed (see above) it's a dead end, unless you have a 384000 (352800) DAC.

All 'n all, right now, I don't see where HDMI comes into play. But hey, I sure can't know everything, so if anyone knows more, please tell it and consider this as (well meant) BS.

Peter

The only thing 64 bit will bring more is supported memory, which ... you can't utilize anyway (2GB max can be used by XX). Also, by now (version 0.9w-3) it is not necessary anymore.
I think, though, your DDDAC will just work on any legacy USB driver, including the one within 64 bit Vista.

I hope I am a bit clear ...

The size of the split shouldn't really matter, as long as it is not too small. So, 300 or 400 or 600MB it all doesn't matter (and most tracks fit within that anyway).

What does matter, is the clicks in between the splits (which are there at track boundaries just the same). So, I don't know what system I have, but I just hear them all the time. Just built in some "leds" in the software in order to show where I think they come from (which was confirmed by now), and tonight I *WILL* get it out of the way. Getting crazy of it, and I just don't know why it happens (at knowing *where* it happens).
The upside is that it is easily repeateable, and happens after 30 seconds or so of playing. This is different from when I worked on this before for such a long time (last April), when it was not repeatable (and the ticks were louder).

Note :
You may just as well forget about the "Start immediate" checkbox (hence you can have it ticked), because it was a theory I had that it could differ. But I don't think this was confirmed.
Kind of importantish : at UNticking this checkbox, tracks regulalry will play double, and after that playback stops. I noticed this before (and mentioned it somewhere) but it seems that this is caused by this checkbox being unticked (never noticed it otherwise). How this is possible anyway is another matter, and so far I can't find the cause.

Mwah ... I am not sure bluetooth is sending/receiving without doing anything (but I think it does like wifi), but in the end it is not only about that. It is about that you sure want to move your trackball and type a key here and there, and then this stuff usually has priority over everything (which is kind of logic) and then the sound breaks ... (ticks and stuff).
On the matter of this latter you can easily try it. The "polling" thing can be checked for, although this is not easy for the unexperienced (for bluetooth I wouldn't know how to do it either, currently). This won't break sound, but may (!) degrade it.

Stupid computers.
But luckily we are so far with it, that it sounds way better than the CDPlayer !

Peter

Officially (at least that's what I know of it) the raw DSD stream can't be output from an SACD player (it's not allowed, whatever). But, from some players it can be picked up, and the Oppo (don't know the type) is known for it. It you Google around a bit, you will find it.
You'd have to take up the solder iron though ...

Btw, I don't own an SACD player, and there was nothing in my mind that planned to use the DSD input. But about theoretical options ...
Peter

Good question and an honest answer : currently I don't know yet.
I think anyway the Oppo is known to be able to capture the DSD output and the ESS Sabre for sure is able to digest DSD.
But as with all features from my second list above, they have to be created explicitly. So, that is a theoretical list and I can tell you ... to implement them all may take many weeks. Besides that, some connections just go over Firewire, and others require dedicated inputs + input switches. So please remember : what I listed is indeed theory only and allowing for it all at the same time would require a "switchboard" which may look virtually imposant, but which may be undoable at the same time. This is exactly why this "routing stuff" goes by software these days, which ... requires the programming of that. It may look all nice for you, but is a huge task for me at the same time. I think ...

Peter

That is correct.


which is only about mentioned (2) and (3).


Which is most probably because you are using XP hence Engine#1 or #2; most of the features depend on Engine#3 hence Vista ...

SQ difference between the Demo and normal version are unintentional, if there at all. However, the determination of the running version being Demo or not *is* in the (software) playing loop, which can't be avoided because of the applied principles (XXHighEnd being a "memory player") and which largely comes down to "unattended playback" (while checking for Demo keeps on being necessary) which btw is literal with Engine#3 and the Unattended setting. For Engine#1 and Engine#2 there is a much higher chance this is audible, but then the Unattended Playback mode was made for a reason (keep distance from unrelated - though SQ influencing software).

I hope I could make it a bit clear ...
Peter

Neither. But it is passive anyway.

If it interests you : any transformer just kills transients, "sharpness" and sprankling following that, never mind it's passive.
OpAmps ... well ... YMMV but if they're not noisy they colour the sound (ah, I am very much generalizing here).
Tubes ? hmm ...

Tubes can colour, but IMO this is unwanted. I think they can just as well be neutral if picked properly for the job.
People say tubes are slow, which I personally don't believe. What I do believe is that tubes don't last forever and I can't stand that I'd never know when they are worn out. But that's personal.

All'n all passive is the more sure way to go for. If it can be achieved of course. Anyway it was one of my sure objectives and requirements, friendly met after politely asking.
But who knows ... when the I/V was setup in an active design (as it originally was so), what would have brought *that* ?

If I may say so ... my TwinDAC+ also takes this explicitly into account ... but it just hasn't got the drive for longer interlinks. But hey, weren't we suppose to use pre-amps ?

Hahaha, wait a minute pedal ...

What I expressed for features and all were not much commercial expressions, but merely what I had in mind for myself. I little show-off if you like ...


As the original features show, a terminal is there for an external clock. What they don't show, is that a BNC input for a word clock is there too. However, for me, myself and I it would not be connected. But it can be ...
The configuration as I have it in mind  (and which is just there, although not everything is connected) is as follows (besides the beforementioned in the first post) :

- As said, BNC Word clock input;
- Direct TOSLink S/PDIF input;
- Firewire input 2x (useless by itself, by see below);
- AES input (over Firewire);
- S/PDIF input (over Firewire);
- ADAT input (over Firewire);
- TDIF input (over Firewire);
- Direct I2S receiver;
- I2S input 3x (over Firewire);
- Direct S/PDIF receiver 2x;
- I2C interface;
- Each of the above also available as output (not Firewire);
- Some more Pro stuff;
- Last but not least : DSD input.

Huh ?

The last mentioned "feauture" needs some additional explanation :

During the process the ESS Sabre DAC came available (I think March this year); Besides it has the best specs ever, its internal working is very much similar to my own design about the 32/384 DAC for jitter specs and more. My "DAC" will contain the ESS Sabre as well, and although it is a (heavy) oversampling DAC, as said, the specs are special. Otoh, the jitter specs are not better than the DAC I have running right now ... in oversampling mode.

Here all are apples and oranges again, currently knowing that the oversampling mode of my "NOS1" just doesn't touch it. So far I tried each night, and it really doesn't last for one track ...

Besides that, when I really implement the ESS Sabre (due here for a couple of weeks) it won't fit in the same cabinet. But then I anticipated on that with having two cabinets with sharing connections where needed (like the inputs, outputs, some PSU parts and routing switches).

So do I overdo it ? probably yes, and out of all available options and combinations only one will be used. However, there is a significant difference with how I had it before :
Before, in my case, always the Fireface was the intermediate. It was the "routing" device, but it always routed over S/PDIF. That now can be avoided, because the DAC can be its own router. For example : any CDPlayer, DVD(A)player, DATDevice, SACDPlayer, SATReceiver and the like (??) can use the DAC as a DAC, and it is not PC-dedicated. In the mean time, there's nothing that makes it dependent on the PC (the direct Firewire connection causing that, and - upside down - a soundcard is not involved hence does not disturb).

Did I mention USB input ? No. But optionally it is there too, but now completely without reason *and* currently it doesn't support 24/192 (and not DSD of course ... afaik).

What can I say ? not any element was designed or created by me. But with some soldering and driver programming it just allows for all.
This "all" is just about backups. Right now I again enjoyed for several hours the SUPERB bass coming from this single - far from optimal - connection. All still unshielded as the picture in the first post shows.

Peter

You are completely right of course, and I didn't mention that on kind of purpose;
Firstly, it is relatively less important than having to use a complete other DAC as how it was before (with me).
Secondly, I didn't want to confuse things unnecessary, because I first have to see whether the larger buffer still makes a difference. And in other words too : whether XX can still make a difference by means of the various settings.

The latter is very complicated because not is all known (not by me anyway), although this project / DAC might be just the test pilot to find out. I mean, whether all is PSU impeeded (which whould be unable to influence in this case) or the jitter (which is completely detached from the incoming stream in this case *if* oversampling mode is used (which I won't hehe)) ... it shouldn't make a difference anymore. Shouldn't, but it will take some ages to test everything, while I'm not even through the base of it all.

I didn't use 0.9w-3 because I think it is better or whatever; instead it was just lazyness with the combination of nothing being shielded yet, using unshielded cables all over ... well ... look at the picture. It is just impossible to be the best right now, hence it is useless to try to squeeze out the best of it at this moment. Nevertheless it is the best I ever heard.
Also, it can hardly have been broken in right now.

A complete other matter is that indeed I'm trying to get to the buffer of this firewire connection, and at this moment I can't judge yet what can be done because I don't have the drivers running yet (the hardware should all be set already). If I want I can program the complete firmware and driver (I mean, right from the beginning) so I could make it the best for "our" purpose. But it is not to underestimate, because that would need just another development board (besides the one I have now), and the additional $1500 it takes is not funny, not even knowing what can be achieved with it.
I have to keep up that I am going to produce XXX DACs already , otherwise you don't get access to all the stuff anyway.

You may know I am a provocer of "no such thing as a real bad recording exists until the real proof of it is there".
Well, one of those recordings prone to that is Musicology from Prince, expecially the 2nd track "Illusion, Coma, Pimp & Circumstance";
I recall being at someone else's place, pointing out the extraordinary excursion of the woofer being 2cm or so in one direction, which at normal circumstances should not be more than a few mm's only.

Today I thought about "control" of the DAC in that area, and if one track would prove that, it would be this one.

As you already guessed, it worked out beautifully (to the sense of how "beautiful" can workout for Prince ).

This is a track with rather low synth fundamentals (a bit Madonna like) which in this case before worked out the most rough as possible. It just made vomating (a bit of a dutch expression) the woofer before. Just completely out of control as how it came to me, although without really knowing, and virtually blaming it on the "bad recording" (like completely overstreered). But today ?
Ha ! not so today. Today it appeared to be an indeed low synth bass line, but with a bunch of higher frequency harmonics, just "good" disco like.

Might you have the album, try it. But uhhm, output should be at an average of 90dB @ 5m distance. Run this at a lower output, and it's just some fumbling around.

Good control of a DAC ... who would have guessed that ...