Clarification on Intel's SST versioning scheme, is it hardware tied?

[KaoDome86]

First of all, if this is the wrong category for the question feel free to move it where it'd belong, I just couldn't find anywhere it felt better.

A bit of introductory details, I have an Acer Aspire A515-54G shipping with an i7-10510U and its soundcard is a Realtek ALC255 routed through Intel's SST; so it's a 10th gen Comet Lake system with an ALC255.

The official drivers are stuck in time (as usual with them) in 2019, not only that, but because the laptop also shipped with older processors for a while (8th gen?) the SST version bundled in the Realtek audio driver package is from the 10.23 line.

Now, I know SST versions are kind of matched to the machine, for example, I don't know if it's possible, but it probably wouldn't be wise to use a, say, Dell SST distribution here (even if hardware IDs for the controller or OED matched).

What I'd like to know is if versioning of SST is related to the processor generation. It's something that came to my attention recently, but I think 10th gen Comet Lake would be the 10.25 line. I've seen Cannon Lake and Coffee Lake systems with 10.23s, Ice Lakes with 10.24s, and newer generations sporting 10.26s, 10.28s, etc. Am I wrong in this assumption?

I know newer driver releases don't depend on Intel, but on the system integrator themselves so I won't be asking for newer drivers (although I'd appreciate it), but if at all possible I'd like for someone at Intel to confirm whether the SST driver to use is related to the processor generation (or some other Intel hardware component for that matter).

Thanks for your time anyway, regards,
Kao.

PS. Just in case, these are the hardware ID for the controller in my machine:
PCI\VEN_8086&DEV_02C8&SUBSYS_13451025&REV_00
PCI\VEN_8086&DEV_02C8&SUBSYS_13451025
PCI\VEN_8086&DEV_02C8&CC_040380
PCI\VEN_8086&DEV_02C8&CC_0403

[n_scott_pearson · Accepted solution]

The SST driver is actually dependent upon the hardware ids of the SST bus implementation present in the PCH component. It is thus dependent upon the chipset series. So, to the extent that a processor generation is also dependent upon (compatible with) certain chipset series, it could be said that SST driver version is somewhat (i.e. loosely) dependent upon the processor generation.

Remember though that the SST driver version required to support one chipset series may be different from that required for another chipset series. The SST driver installation package that the vendor is packaging with their CODEC installer will contain all of the SST bus driver versions that are needed for the various chipset series supported the SST bus. This obviously may be a superset of the chipset series being targeted by the CODEC vendor.

Clear as mud?

...S

[KaoDome86]

I see! It's clear enough, thank you! I knew there was something amiss in my reasoning after seeing different driver packages from different vendors, but I couldn't quite put a finger on it.

Hence the unwise decision of trying to use packages from a different vendor, I've personally never tried it, looking at the packaged files I could already see they didn't seem interchangeable even if series matched (e.g., in the one Acer provides for my machine there are several data files in the firmware folder (FW) that aren't in others, and vice versa; same with the things inside WoVartifacts, maybe even topology changes, who knows).

So for those that stumble upon this thread, even if hardware IDs match it may not be as easy as replace one distribution with another, best to stick with what your manufacturer provides (maybe looking if there are other models with the same chipset in that manufacturer that have ship with a newer release and give those a shot).

For me, 10.25 it is, its chipset is a Comet Lake-U (PCH-LP Premium).