XXHighEnd

Guys, I think it's time to discuss our experiences and preferences regarding different settings, but let's put the Engine and Q parameters aside. I'd like you to focus on:
- Processor Appointment schemes
- Player priority
- Thread priority
- Buiffer size
- Split size

Here are remarks froim my side. What you're about to read has been tested many times on 2 PCs.

CPU Appointment scheme

In my opinion there are 3 settings worth mentioning; No Appointment, Scheme 2 and Scheme 3. Schemes 2 and 3 are musical flavoured and No Appointment is neutral flavoured. I prefer No Appointment myself, cause it's the most transparent. Scheme 2 has rich midds and delicate highs, good for vocal music IMHO. Scheme 3 however is more detailed in the upper area and with bass emphasis. All schemes sound better on a single core CPU.

Player priority
This has slight effect, but I don't know what sounds better - low or nothing. I'll investigate it.

Thread priority
When it comes to playback thread priority, SQ depends on it a lot. Realtime is the most detailed and liquid, while high or normal (Nothing) are more relaxed. CPU's behaviour differs vastly in both cases as shown below.

Buffer size
1024 samples seems to be the sweat spot for me and my system. Higher values, especially 4096, give better imaging but overall characteristic become sharper and thus I prefer 1024.

Split size
Currently I have it set at 64 MB. I don't know if it matters or not, but I'm kind of used to 8 multipliers (IT branch, sorry :D). Maybe Peter would shed some light on it. Is there any pattern for setting the split size, e.g. sample rate dependent? I read somewhere that smaller values work better with upsampling. I don't care about CPU/memory behaviour, there is only one thing on my mind, which is known :)

Best regards,
Marcin

Marcin,

How can that be as there are scheme settings that are made for splitting things between 2 core's? You talk about 1 core. How can that be different?  :scratching:
 
Peter?

Good question Gerard. I think it can, if the way the second (and more) core is shut off is not official. On this matter, notice that as far as I am concerned this should be at the HAL  (Hardware Abstraction Level), but this may be outdated thinking. So :

When this is not done officially enough, the program still thinks 2 (etc.) cores are there, and the assignment takes place anyway. BUT, one half obviously doesn't work in reality, and although the results will be unpredictable, it *will* matter.

Notice that this is wild guessing, because in the end I don't know.
But wait ... Marcin, if you could upload an XX log file from a Playlist with FLAC conversions (6 tracks or so is enough) I can see whether the program still recognizes the cores or not. Can you do that ?

Peter


PS: And Marcin, I wanted to ask you what you do for a living, which you coincidentally just answered. Still I have the question, because it looks like you have ages of time for this all ! Added to that : your various reporting and sharing is much appreciated. I guess not only by me ...

No, there no relation between the split size and something else (like sample rate). But, there *is* an obvious relation between the load the just read part incurs for, the time it takes, and the influence on SQ regarding ticks or even gaps. But theoretically also : the longer the "loading" sustains, the longer it influences SQ generally. And that being said, the next what counts is the shorter it takes forces by priority settings, the more SQ will be influenced BUT depending on how your system is organized. With one core this should count for 100%. With two cores it depends on the Appointment Scheme used, with the very theoretical possibility of just looking at the graphs.

It is all rather complicated because in the and ALL is related, and the subject sure is too large to explain more or less briefly in a topic like this. That is why I started a topic about it a few weeks ago, but I never got round finishing it, thus far.
For now I could say : play attention, pay more attention, and pay attention to everything, and from there you will learn. On this matter it is very easy to know more about it than I do (I just provide the possibilities), because I hardly have time for it. But this is why we are with many, and all observations help.
And in the long term there will be a new "SQ" version, making use of the observations. Tadaa.

Peter

In all cases everybody MUST assume judgements like those from your original post are about Unattended. Everybody who likes to think otherwise, well, please don't. :)

With this in mind, PlayPrio can only "disturb" playback, when not set right. So, it is about the "attention" the system is allowed to pay to conversions (right before playback begins) when "Start during playback" is active, and it is about how fast a remote command is dealt with during Unattended playback (because it is the "player" dealing with that !). It is not so difficult to see with this example :
Set Threadprio to low, and Playerprio to realtime, and as soon as you hit VolUp most probably playback will stall briefly, and the volume will turn up. However, chances are fair that you end up with noise right after that, because all synchronisation may be lost. Difficult to explain, but think in terms of buffer errors.
Now the other way around : PlayerPrio to Low and ThreadPrio to Realtime. Now the remote command may wait and wait and wait for maybe even 20 seconds to get dealt with, because the playback gets all the attention. In the very end in will work, and it won't disturb playback at all. So, in this case, actually, playack disturbs the remote command.

In neither situation this is related to SQ, because no matter what, both don't live next to eachother long enough with equal force to influence SQ. But as explained, it will be about literal "disturbing". Or physically bcause of noise, or psychologically because of waiting.
Looking at the graphs from Marcin also helps. You can see that with low prio the process takes longer. You can not see it does that with less "force" (in this case) but this is so. But now it influences longer ... but less ... etc. blahblah.

:whistle:

Hi there,

I just set Q9550 in msconfig to 1 core, checked it with cpu-z and the flac converting behavior in xx itself.
1 core is being used.

But the sound is awfull, it sounds like a cd-player all over again, definitely not better at all, it sounds like 2x mono.
I will try to make it sound "more" right with changing some settings/schemes, later on.
I also try to use 2 cores instead of 1 or 4

Marcin your work is definitely appriciated, but obvious answers are hard to find, everything influences you know this by now.
So keep it coming.
But I definitely hear you: its not hard to get lost in all those settings and schemes.

Later..........

I graduated IT and Econometrics.  I've been IT journalist in CHIP magazine for few years. Currently CEO in 'interactive' agency (mostly public relations activities for IT/CE branch but also webdesign). The reason why I spend so much time on it is, that I want to start my own project, similar to Computeraudiophile. I've been gathering 'wisdom' for some time now and I have good (imho) topics for articles that you can't find anywhere over the net. Besides, I'm a musician too and, well, I love it.. :) Oh, did I mention that I'm 25? :D

:offtopic:

All it lacks is living in Krakow. One of the greatest cities to be for a "western boy" in love when the Wall was still there, and when you could buy a complete bucket of roses for 1 USDollar for your woman, sneaking in one of those cosey backyard icecream cafés.
And where you can drive uphill with your car without the engine on of course, at the top meeting one of the finest restaurants.
Milicia on every street corner, but those were the days ...
:)

[OT]

Haha, nice memories ;) Thanktfully these days are gone and we live in a democratic country, are we?

I live in Wroclaw, also a beautiful city, but flowers are a bit more expensive here... :D

[/OT]

Peter/Marcin,

You guys have just redefined 'off-topic' for me!

Marcin, good luck with your new 'computeraudiophile-like' endeavour... But as well as focusing on the absolute leading-edge in CA, I think there really is a market for helping 'regular' audiophiles enter into the world of computer audio. I know of many who are holding off for two main reasons:
1) they are infinitely knowledgeable about 'regular' audio but just feel 'inadequate' wrt to computer audio
2) they are waiting for more 'true' hi-rez material to appear - but as we know here, processes like AP can perform alchemy on 16/44.1 CD rips (perhaps AP will be considered the true audiophile 'Philosopher's Stone' in years to come)

Mani.

If you only put the emphasis right. And to do that right in this small sentence is a delicate thing, and most probably not what you wanted to express. Haha.

Hi,

I thought that using Adaptive Mode/Arc Prediction the buffer size should be set exactly to the buffer size of the soundcard. Isnt this still true?

My soundcard's buffer size is 128 & that is what I have set. Whenever I have tried to increase it the SQ drops. So in my case the initial theory holds true.

Arvind

Hi arvind - this is still true. But not to forget : this is for achieving the lowest latency in Adaptive Mode. It is not said that this sounds the best; that is just another matter ! (and most probably subjective). So, nothing wrong at sticking at the buffer size value.

Peter

I played around with different firmwares and drivers from few vendors and here are the results of my battles:

* drivers affect SQ and it's not a small impact

* there is no 'gold' rule for best buffer size (regarding SQ), core appointment schemes etc. For example; ESI firmware and drivers sounded the best with lowest buffer size (48 samples) and scheme 3, but with 2 CPU cores activated! (Roy, I perfectly understand your disappointment...)  Although low latency playback worked great with ESI software it didn't sound 'right' for me - to analytical/technical/clinical (pick whatever you want). Eventhough everything seemed to be there, great, punchy bass, lots of details, but I missed the flow of Cantatis/Via drivers. In other words, I couldn't find the setting that would not 'hurt' my ears with ESI soft. All and all I got back to Cantatis software (older version based on VIA 5.20 drivers) which sound the best for me and my girlfriend, who is now sleeping like a child and not complaining about loud music :)

I've flashed my Cantatis with ESI firmware again in order to try Special mode with low buffer sizes. Encouraged by Calibrator, I switched from my 'reference' settings (see signature) to DAP instead of QAP and KS Special Mode with Q1=-1 and buffer size at 48 samples - yep, it's possible, these drivers are awesome and I don't need ESI card to use them, great. After play button was hit, I heard not only 'more' but in a more realistic way. Then I figured, what the hell, QAP is 'supposedly' better than DAP, but no, at least not with my card and my system. Next thing I've done was going to redbook - 16/44 (DAC set to 16 bit as well) with intert ticked. Now that I've played couple of albums and compare it A/B with DAP and QAP, it's the best sound I've heard so far. I don't know if it's due to ultra low latency (2 samples?), because I can't play QAP with these settings (have to increase Q1 to 5 - 48 samples) or simply upsamling doesn't go along with my card and DAC on it (delta sigma), don't have a clue. I'm 100% sure that it sounds better though - I am able to hear more details and it's so realistic that I get a goose skin over my head. So I have a hint for you guys, if you don't have a NOS DAC, just stop for a moment, don't pursue this 'upsampling' journey, try good, old 16/44 with following settings (if your drivers allow it):

Engine#4 *Special Mode* / Q1/2/3/4/5 = *-1*/0/0/0/0 / *Invert* /  Playerprio = Low / ThreadPrio = Realtime / Scheme = 1 @ UnAttended / Services Off / No Upsampling / *1024 samples* / DAC set to 16 bit !

Hahaha, nice Marcin !
How many samples of latency is that ? (see X3PB log file)


PS: Are you ever listening to music ? :dancing:

I'll check that tomorrow, but most probably it's the same as Calibrator's (the same drivers), so that would be 2 samples, but finally I can relax on my couch and listen to music  :soundsgood:

I checked X3B log and... Samples of latency (Q1) : 1

No cracks, no crashes and I found a workaround for memory playback. I 'cut' my albums to separate tracks, never load a single track-album. This way I can set split size to 1024 even and no problems at all. Peter, is this full memory playback?

I am sorry, but I don't understand what you did !

Go back few posts and you will know. I wrote that I flashed my Cantatis with ESI's firmware and used their drivers as well. What I didn't write is that I 'unlocked' the second core and increase CPU frequency. 1.4GHz dual-core is enough to provide fluent playback of 16/44 material with 1 sample latency. What else didn't you understand?

This :


?

Album-as-one-file -> cue -> album as multiple tracks-files

This way XXHE handles memory playback differently and I don't get to see 'OutOfMemory' errors.