Clicking/popping w/ unpadded 16bit KS output - KS only supports 24=> bit output?

[numlog]

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?

[PeterSt]

Hi Laurence,

First off, you surely can be right that something is amiss, because I have no way since long to check for genuine 16 bit output as I have no DAC for that. Otoh, I feel that you are not obeying "rules" or "laws" at the same time. So, not sure …

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.

We can't just "require" to cross the boundaries of physics. I mean, yes, we might like that for perceived SQ reasons, but if something can't cope, it can't.
Ever back the lowest we could go was 1.00 and the fact that we now can do 0.06 or some times (not me) 0.05 is because special prerequisites were created, found in various other combined settings (don't ask).

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

Same thing - you can't pad bits on a 16 bit DAC beyond 16 bits. Maybe you can tweak the lot alright like telling the program the DAC is e.g. 18 bits, but then you are cheating or lying and nothing can work as intended.

So you see, you are a bit prone to pilot error.

Check the KS Mode setting; If that is set to Special, I'll bet you that's the cause. Set it to Adaptive instead. Note : Special uses a special KS buffer means; Not each DAC can handle that which actually is a deep down inherent OS bug (our own NOS1 can't either).

Notice that not only the SFS, but also the net result of Q1 are buffer(-length) settings and at knowing that, you may be able to detect which of them "doubles" the time a glitch etc. stays away by doubling the number of the setting (this works out almost linearly). A driver control panel for your DAC - if existent - may also influence buffer lengths.  The ClockRes may also influence slightly, but I would not blame that easily. Still it can imply "resonant" OS behavior, the OS choking at regular intervals (which can easily be at more than 30 seconds).

Q3,4,5 influences as well. The implied internal settings are eased when they are all set to 0.

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...

Unlikely. At least I never heard of it.

Regards,
Peter

[numlog]

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.

[numlog]

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

[PeterSt]

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

Sadly No. My DAC can not be operated in 16 bits (and ditch the inherently present extra 8 bits). Maybe it could have made like that, but it just wasn't …

and I assumed that setting to 16 bit should not affect the SFS limits possible at 24/32 bit.

H*ll yes it does ! You are throwing out half of the buffer length. Think the other way around for your comfort : if 32/44.1 is played, the SFS buffer lasts twice as long vs 32/88.2. All is different now … (and now extend to 32/705.6).

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.

That is indirectly what I meant in my previous post, but slightly differently approached … You can't upsample 16 bits material even to 2x without adding a bit. So you can't upsample at all. Oh (and again) you can try to tweak things, but again it will fail similarly.

Do notice that I could have made it so that 16/44.1 can be upsampled to 16/88.2, but you'd have a strange kind of distortion because of twice too "small" (finer) jumps in sampling rate vs not-at-all-possible jumps in bit depth. This must be/remain in balance. Maybe an other player can do it, maybe you like the different sound for the better, but it *is* not for the better. It would be illegal to do.

Best regards,
Peter

PS: Does WASAPI also doesn't work out for you, in this case ?

[numlog]

Well thanks, that explains it.

Usually when limits in SFS were encountered, which was only with WASAPI, the results was below a certain point the sound would just stop, but that's WASAPI.
But, based on what you're saying, with 0.02 being possible at 24bit, at least 0.04 should be possible at 16bit?

To elaborate on the sound of this issue, there is no affect on timing of the music, only  cracks/pops/clicks like you'd find on vinyl but louder.


About trying WASAPI, right now I have server 2019 Core on a 16GB optane drive, this was only OS which will fit on this drive.
With the newly add ''FOD'' feature in core and AudiophileOptimiser it was possible to get WASAPI, KS and desktop-like environment. XXHE works in S2019, buts very problematic, seems to recognise the OS as ''XP or older'', so a lot of features are restricted,which includes WASAPI.

Having the SATA card and SATA drive dedicated to storage and Optane as OS has given the best hardware performance so far... Perhaps in the short-term made more sense to go for 32GB option, but next gen Optane drives are on the way.

Anyway XXHE filtering was a good and convenient option but there still remains the more traditional option of using an analogue reconstruction filter for this 16bit DAC.

[PeterSt]

This is from the Release Notes of 2.08 :

•There's official support now for Windows Server 2016 (and an OSIsW2016.tss coming along with it, to be renamed to OSIsW2016.tst in case WS2016 is not automatically detected - see Release Notes elsewhere).

I am almost sure that if you apply this now, thus act as if this is WS2016, this will work all the way, unless there's something special in WS2019 what I don't know yet.

Otherwise in 2.11 there will be the OSIsW2019.tss file for the same purpose.

Peter

[numlog]

Thanks, Peter.
The S2016 file had no effect, funnily XXHE does recognise as ''Server 2019'' when no tracks are loaded into playlist and with S2016 tss file it still does. Using W10 file instead worked , recognised as 'W10' with features restored and working

Clicks and pops correspond to the lower SFS just like KS, but im being pedantic as large SFS sounds just as good and work perfectly.

[PeterSt]

Ha !

but im being pedantic as large SFS sounds just as good and work perfectly.

Can you help me out here … What exactly now works ?
Or is this about the "W10" support that it started working ?

Also, what is the lowest SFS that you roughly know of that still works OK ? (no need to re-test as "roughly" is indeed sufficient for me).

Peter

[numlog]

With SFS above about 2.00 there are no clicks/pops . it always worked like this and I wonder why I made this thread when the solution was already discovered, though S2019 was a real problem with an unexpected fix.

[acg]

Numlog, I am not sure if you are aware, but how low you can go with the SFS is dependent upon the AudioPC cpu clock speed.  The more it is underclocked the lower you can go with SFS before experiencing the clicks and pops.  So when you say the pops are a software thing, in my eyes you are sort of right but the more complete picture is that it is the computer hardware that influences SFS, and in particular the cpu speed (underclocking).

At least that is my experience.  Of course there may also be other triggers.

[numlog]

I wasnt aware and thanks for bringing that up, reevaluating CPU underclocking with this Ryzen CPU is something that needs to done.
The possibility of it being PC hardware related makes total sense, when I said software I only really knew it wasnt related to anything after the PC (DAC, USB interface). It could not be influenced by software settings, only SFS which itself is influenced by CPU speed.

[numlog]

With underclock weirdly I got the 'WASAPI silence' on KS, usually min 0.02 is possible but with UC I had to increase to 0.11 to get sound.
No help for  the popping with 16 bit

[numlog]

I notice ''special'' KS mode works for me now using an ESI Juli@ XTE PCIe card for I2S output to my DAC. Special mode never worked with USB interfaces, and the problem was always the same even when every single thing in the system had changed, the music would play normally but have loud crackling on top, similar to the original issue mentioned in this thread.

It works now with this PCIe card and it sure does sound good

something to note, with any upsampling on special mode I start to get pops, I wasnt able to fix it by changing settings, other than going back to adaptive mode, so not much use if you need upsampling.

[PeterSt]

Haha. KS Special Mode was made with the Juli@ as (test)subject.
So yes, that works all right. And for the way better SQ …

Peter