you may be able to recreate it on your end with your 0.06 SFS and 16 bit?

Hi Peter,
The same 16 bit DAC chip and USB to I2S interface works (virtually) perfect with the 24 or 32 bit output in KS (and 0.02 SFS, adaptive), it also occurs with a 16 bit output to a 32 bit DAC... only that is pointless so wasnt mentioned. The only change that happens for the problem to occur is setting output to 16bit, and I assumed that setting to 16 bit should not affect the SFS limits possible at 24/32 bit.

this is semi-DIY stuff btw

I also notice Arc Prediction appears to be intentionally restricted at 16 bit, which implies even ''forcing'' by setting to 24bit that AP will not work correctly with only a 16 bit DAC.  too bad, AP already sounds great with DS DACs, and was hoping to use with this multibit NOS DAC.

Confirmed with many different DACs/different USB interfaces that this is definitely on the software side.

Im using a multibit 16 bit DAC chip. Bit padding in software for redbook is having some slight negatives effects on SQ so avoiding that is desired, however setting the DAC to 16 bit with KS output is causing some clicking/popping over the music.
increasing the SFS to about 0.5 or greater reduces it to basically nothing but the odd pop/click is still audible, and lower SFS is desired.

I feel like I read somewhere, either in help box or on the forum, that KS requires 24 bit or greater DAC but cant find it again... maybe thats the issue?

Ok I understand, the server PC you describe sounds like NAS with XXHE on the audio PC,
usually (or sometimes) the audio PC is only a DAC interface and network interface to server... that isnt preferred here?

I do use single PC, using a server seems like the way forward but improving things on single PC is still possible, sometimes in undiscovered ways, it can be interesting.

Using the RAM disk for playback since was an improvement only with a strange difference. Previously the best sound was achieved with XXHE installed to storage HDD, assumed to be benefit of local FLAC decompression.
Now with RAM disk for playback, XXHE installed on the OS drive/SSD is now better but only with the HDD still used as storage.

you also mention this in ramdisk thread I notice, the install location matters, even though software runs from RAM (I guess at this point it shouldnt be a surprise)

It allows it to go higher but how high before something goes wrong im not sure. Usually its needed for stability when overclocking.

RAM speed is supposed to be an equal factor in the ''true latency'' of RAM, so you could do it the opposite way with overclocking - maybe thats better, but very high speeds are only supported with recent hardware. (my mobo and CPU are limited to 2133MHz)

This is probably obvious to most but RAM latency can be adjusted very easily, just like clock speed.


When underclocking, if RAM timing is set to auto latency will be lowered automatically depending on how low the clock speed is set, this could account for some of sound difference with underclocking, which itself might make things worse.

The latency is adjusted to very safe calculated values that corresponds to the decrease in speed, with manual setting I was able to siginificantly timing settings at max 2133MHz speed. e.g CAS went from 14 to 5 and somehow works with CPUz reporting it, others were also lowered to a similar degree.

Its been over a month and I only realised now that ''playback drive'' is something that can be denoted in settings.

This was explained in the RAM disk thread, incidently a RAM disk sounds like the simplest and most effective use for a playback drive (if you have capacity to spare).

Using a typical (HDD or SSD) dedicated playback drive im sure has benefits, but inevitably complicates the system.

but the the program SQ wont benefit in some way from the faster SSD, like lower latency or the same reason a fast SSD sounds good as an OS drive. i was ignoring PC basics, programs run off RAM 

Laurence

much clearer, thanks.


well that was a lot of time wasted being stuck on the idea XXHE should be stored on OS drive, thanks to you a whole lot more time (and hard drive space) has been saved. 

I understand, you can call me Laurence.

Using a HDD for storage has objectively better SQ (on this system) than a storage SSD or OS SSD. I noticed this with FLACs but that makes no sense, it always the WAV conversion on the OS SSD that you hear.
others on computeraudiophile confirmed HDD are better for storage.
WAVs on the HDD is even better.

flac conversion wasnt able to correct the header data, if that is the problem with the wav.
I dont understand the explanation, but all I was wondering is if you had an explanation.

not an issue but something very very strange that popped up today and this is the most appropiate place for it.

all WAV files created with Aul converter will not play with wasapi in XXHE no matter what. no error only a short blue flash of the kill engine button

to highlight how specific this is:

• only aul converter. attached are 2 flac-to-wav conversions from aul converter and another conversion software, freac, of the same source file. I probably changed every setting in aul and still nothing...see if it plays for you (dBpoweramp, foobar wavs also play)
• only WAV, converting to any other format will play.
  
• only XXHE and only wasapi. KS output, ASIO,  HQP/Jriver/foobar w/ wasapi - no issues.
  none of XXHE settings could make it play.
  location does not matter. same folders, different folders, same name, different name,  OS drive or external - nothing.

although strange it isnt the first example of hidden differences between WAVs, the reason of using aul converter in the first place is that the quality of XXHE's internal FLAC to WAV conversion is better than preconverted wavs from freac, which itself is better than foobar wav conversion.
Since a true need for pre-converted WAVs arose (to avoid copying to OS/XXHE drive for playback), I was trying aul converter as a better alternative to freac.

just want to add something that might be very important for some.
BIOS settings got wiped today after a hardware change, after changing back all the settings and booting up the sound was not good at all. rebooted into BIOS and there was one setting I didnt disable: CPU SVID support

Disabling SVID sounded better with default CPU setting when testing it way back but according to some post in an overclocking forum SVID  should be disabled specifically when you're using manual core voltage,
its not overriding the settings at least (BIOS still shows the core voltage I set when SVID was enabled) but it critical for good sound.

This was really helpful advice, the biggest issue at 44.1 was bass, a lack of definition and extension. it must be as you say because 88.2, like 705.6, fixes this entirely. same benefits with much shorter buffer, along with generally nicer sound (less load?).

xtweaks is worth mentioning.
Based on the descriptions 'nervous rate', 'provide stable power', 'utilize cores' sound like they should behave the same with CPU clock and voltage changes so I ignored them. There are options for C-states, speedstep and Turbo Boost in BIOS which are disabled, from the descriptions they sound like they could be the equivalent to Utilize core and stable power settings.
 
Balanced load is confusing, based on listening a while ago the low balanced load settings gave better results with default CPU settings. From its description you could assume the lower BL setting would be bad  with heavy underclock/volt, when the CPU peak state is already slow/cold, yet the BL low settings give similarly good results... im not sure I understand BL but some consistency is good, less need to worry about BL interfering the effect of the BIOS tweaks

CPU. there was a similar effect with RAM underclock only worse, which you also noticed... I wonder where the benefits of higher RAM speeds end, if we should be using the fastest RAM we can get our hands on.

There might be something to undervolting or overvolting RAM, since the last post ive switched to 100mV undervolt instead and this sounds interesting too ... it takes a while to figure out if these small differences are improvements or not, or if a more musical/lush/vibrant sound isnt adding some form of distortion.

If its available to you another setting with some potential could be ''PCH Core'' voltage, which apparently feeds the chipset which handles all the USB, SATA, PCIe communications. It was possible to drop it from 1.0V to its minimum 0.8V, all is stable and AFAICT sound quality has improved slightly.

Thanks for the support on this