XXHighEnd

Hi all,

With a small apology to everyone not being able to play with Kernel Streaming (yet !), I thought it would be good to express my own ideas about how to "play" this sound engine;

First of all, try to imagine everyting the exact other way around as how Engine#3 should be dealt with. So, the general idea about Engine#3 is : the lower the latency the better it is. Ok, this is not really about latency but merey about "interaction with", but the lower the latency, the more interactions happen, and it is not really important with what that is (there is a whole chain of buffers and things and each work out to an individual latency, ending up at the DAC for a net latency).

Without unveiling what I'm exactly doing in this area, think of a means (!) to achieve this, implying the highest cpu useage. Not that you will have noticed this really, but for example, setting the latency of the driver('s buffer) to a low setting (when you can set that) will show a higher cpu useage compared to when you set this latency to a highest value; at "knowing" that it works like this, you will be able to proove it for yourself, I'm sure.
So, the more interactions needed, the higher the cpu useage will be, and you could say Engine#3 is based upon a high amount of interactions.

For Engine#4 (Kernel Streaming) we must think the exact other way around : It is based upon the lowest amount of interactions, and therewith implies the lowest cpu useage (remember, the latter is just the result of the former).

Now, since this is the major difference between the two sound engines, I started to think it can well be that it is this which makes the sound so different, Engine#3 being the technical/analytical one, and Engine#4 being the less accurate, but emotional one. Of course, deep inside the whay the data flows through the PC is completely different for both anyway, so it would be easy to say "thus that causes it", but what to do with that. And thus, I rather stick to the "means" both engines are driven with, and this is about those interactions I just talked about.

Well, while for Engine#3 we should try everything and all to make the latency as low as possible, this implies that for Engine#4 we must make the latency as high as possible. And, try to understand this is not about the phenomenon latency at all (it will do completely nothing to the sound), but the means to get there is something we can grab *and* will influence the sound;

Half of this means is contolled by me in the program (out of your control), but the other half is in the driver;
For those who can adjust the latency of the driver, it means that it should be set as high as possible for Engine#4.

In my case I now have set the latency to 2048, while the Engine#3 setting is/was 48. Thus, this implies that while the 48 (samples) settings would incur of an interaction each ~1ms, for 2048 the interaction is each ~42 ms. Quite a difference, with the visible effect of the cpu useage being virtually 0 at 24/176.4, while it was between 2% and 4% before (when Core Appointment Scheme 3 is used, the useage of the driver will show in the left core (or "anything but the rightmost" when more than 2 cores are there).


I do not say you will perceive a difference by this, nor do I say I did (I just didn't have listening time after thinking about this). The only thing I say is that it follows a "strategy", so it should work. And maybe to keep in mind : with Engine#3 this strategy is exactly the opposite, and everything I did about that always worked too (in the end prooven by you).
So, it may sound like voodoo, but for those who indeed perceive a better "emotion factor" from Engine#4 so far, should perceive an increased Emotion Factor at increasing the latency of the buffer (not for Engine#3 !).

Peter

?

Peter,

Can if i understand correctly whe can set the latency to a higher level? Where can we do that?

 :)

Oh, these are really good news for me.
Because of my software crossover, I need to keep the drivers buffer (not technically latency) very high. This means that Engine #4 should sound much better than Engine #3 at 2048 samples (that i need to completely avoid disturbs when the latency raises).

BTW, i started to feel the "emotional" character of engine 4. Need only to find the time to listen :)

Hi Gerard,

As said, one half is taked care of by me in the program, but the other half is part of the driver. And, most "consumer" drivers (hence sound cards) won't allow changing the latency (or buffer size, what it actually is). Pro stuff will though (you could say, anything which supports ASIO will).
So, if you can't find anything about it, it most probably can't be changed. BUT :

We can fairly say that this won't be a problem (for Engine#4) because it will be at a high setting to begin with (which is because a higher latency is easier to manage, and nothing (like playing a midi keyboard) requires low latency. Pro stuff *always* requires a lowest latency as possible (try to play a keyboard with a latency of 50ms and you will understand), *plus* that it requires changing it, because the more channels used, the more is required from the processor, so a trade-off must be provided.

For normally playing audio, latency does nothing (but changing SQ hahaha), and thus for non-Pro cards it is always best to use a high latency, so buffers will never run empty (at low cpu power etc.).

Peter