Ryzen 7000 Testing

tomnic · Nov 15, 2022

Dunno If it can help, I've an ASRock Z690 with ALC897, alcid=12, Intel CPU obviously, perfect audio, to try to extract some info from a working similar audio codec.

Besides that, I'll try a simple free game to see if there are stutterings and desyncs just like with sound, WITHOUT speedkeeper:

‎Code of War: Shooting Games

‎Command online shooter - pure action only! Code of War is the online shooter game with the best 3D graphics, realistic physics and the huge selection of actual guns. Try your skills and mastery in the dynamic online action versus other players from the whole world! Become the best and achieve...

apps.apple.com

Even this bench with sound can help, so we can compare real numbers: https://benchmark.unigine.com/valley

Then I'll try to get rid of the fix pat patch now that pciex bus is fixed, or try Shaneee's one if that doesn't work instead of Algrey's default one.

CaseySJ · Nov 15, 2022

CaseySJ said:
Just tried these patches with Monterey because MaxKernel is 21.99.99. Alas, static is about the same.

Let me grab HWINFO / CPUZ information from Windows next. May take an hour or two.

@ExtremeXT,

Attached is the CPUZ report in HTML format. It should open in Safari or Firefox. Windows was booted without OpenCore.

An extract:

Core Speed	5497.0 MHz
Multiplier x Bus Speed	55.0 x 99.9 MHz
Base frequency (cores)	99.9 MHz
Base frequency (mem.)	100.0 MHz
Instructions sets	MMX (+), SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, SSE4A, x86-64, AMD-V, AES, AVX, AVX2, AVX512F, FMA3, SHA
Microcode Revision	0xA601203
L1 Data cache	8 x 32 KB (8-way, 64-byte line)
L1 Instruction cache	8 x 32 KB (8-way, 64-byte line)
L2 cache	8 x 1024 KB (8-way, 64-byte line)
L3 cache	32 MB (16-way, 64-byte line)
Max CPUID level	00000010h
Max CPUID ext. level	80000028h
FID/VID Control	yes
# of P-States	2
P-State	FID 0x8B4 - VID 0xC9 (45.00x - 1.256 V)
P-State	FID 0x878 - VID 0x79 (30.00x - 0.756 V)

PStateReg	0x80000000-0x4B7248B4
PStateReg	0x80000000-0x479E4878
PStateReg	0x00000000-0x00000000
PStateReg	0x00000000-0x00000000
PStateReg	0x00000000-0x00000000
PStateReg	0x00000000-0x00000000
PStateReg	0x00000000-0x00000000
PStateReg	0x00000000-0x00000000

CaseySJ · Nov 15, 2022

And here is HWINFO64...

CaseySJ · Nov 16, 2022

Here are some TSC (Time Stamp Counter) and FSB (Front-Side Bus) calculations performed by following the code below, which however is for AMD Family 17h instead of 19h.

C:

            cofvid  = rdmsr64(AMD_PSTATE0_STS);

            CpuDfsId = bitfield(cofvid, 13, 8);
            CpuFid = bitfield(cofvid, 7, 0);

            cpuMult = (CpuFid / CpuDfsId) * 2 ;

            // Fix for audio desync on APUs
            if (cpuid_info()->cpuid_stepping==0 && cpuid_info()->cpuid_extmodel==1) {
                tscFreq = EFI_CPU_Frequency();
                busFreq = EFI_get_frequency("FSBFrequency");
            }
            else{
                tscFreq = (CpuFid / CpuDfsId) * 200 * Mega;
                busFreq = tscFreq / cpuMult;
            }
            tscGranularity = cpuMult;

CPUZ screenshot shows that this processor has two P-states:

P-State	FID 0x8B4 - VID 0xC9 (45.00x - 1.256 V)
P-State	FID 0x878 - VID 0x79 (30.00x - 0.756 V)

Assuming that AMD_PSTATE0_STS refers to the first of these two P-State vectors (i.e., the highest P-State), we see that the FID is 0x8B4
We also see that the full vectors are (EDX:EAX):

PStateReg	0x80000000-0x4B7248B4
PStateReg	0x80000000-0x479E4878

UPDATE: 16 Nov 2022: JUST FIXED MY BAD LATE NIGHT MATH!

P-State-0 (Vector 1)

So let's assume cofvid = rdmsr64( AMD_PSTATE0_STS ) gets back the value 0x4B7248B4 where the first 16 bits (0x48B4) are 0100 1000 1100 0100
Then CpuDfsId equals bit-field 13..8 which is 0x08
And CpuFid equals bit-field 7..0 which is 0xB4
Then cpuMult = (CpuFid / CpuDfsId) * 2 or 0xB4 / 0x08 = 0x2C (44)
Therefore:
- tscFreq = (CpuFid / CpuDfsId) * 200 * Mega = (0xB4 / 0x08) * 200 * 1,000,000 = 4,400,000,000
- busFreq = tscFreq / cpuMult = 4,400,000,000 / 0x2C (44) = 100,000,000

P-State-1 (Vector 2)

If we perform these operations for the second P-State vector, we get:
cofvid = rdmsr64( AMD_PSTATE1_STS ) gets back the value 0x479E4878 where the first 16 bits (0x4878) are 0100 1000 0111 1000
Then CpuDfsId equals bit-field 13..8 which is 0x08
And CpuFid equals bit-field 7..0 which is 0x78
Then cpuMult = (CpuFid / CpuDfsId) * 2 or 0x78 / 0x08 = 0x0F (15)
Therefore:
- tscFreq = (CpuFid / CpuDfsId) * 200 * Mega = (0x78 / 0x08) * 200 * 1,000,000 = 3,000,000,000
- busFreq = tscFreq / cpuMult = 3,000,000,000 / 0x0F (15) = 200,000,000

Unfortunately neither set of numbers solves the audio stuttering problem. This is how the numbers were entered (vector 2 in this case):

Jaraheel · Nov 16, 2022

Hi everyone,
With the progress reported here, am I correct in my understanding that an external DAC wouldn’t have audio issues?

CaseySJ · Nov 16, 2022

Jaraheel said:
Hi everyone,
With the progress reported here, am I correct in my understanding that an external DAC wouldn’t have audio issues?

It depends on the DAC. My external audio DAC with Sabre ESS902x and XMOS USB still has audio issues, but those issues are significantly mitigated by running SpeedKeeper.

Aluveitie · Nov 16, 2022

the external DAC must have it's own timer to avoid the sound issues.

ExtremeXT · Nov 16, 2022

@CaseySJ Try adding AmdTscSync.

GitHub - naveenkrdy/AmdTscSync: Kernel extension to sync TSC across all CPU cores.

Kernel extension to sync TSC across all CPU cores. - naveenkrdy/AmdTscSync

github.com

First try with IOCPUNumber set to 0 then to your CPU's threads minus 1.

mariettosun · Nov 16, 2022

@CaseySJ could you try to limit your cpu cores as I do in this picture

in your pc you could try to use 4,2,1 (cpus=x)
to see if audio is better (without the trick you have found)

CaseySJ · Nov 16, 2022

Aluveitie said:
the external DAC must have it's own timer to avoid the sound issues.

How can we determine if an external DAC has its own timer? Here’s what macOS shows about the DAC I’m using:

Screen Shot 2022-10-17 at 6.34.32 AM.png

CaseySJ · Nov 16, 2022

mariettosun said:
@CaseySJ could you try to limit your cpu cores as I do in this picture

in your pc you could try to use 4,2,1 (cpus=x)
to see if audio is better (without the trick you have found)

I am currently booted up with cpus=4 and playing my favorite YouTube music video (Disturbed's Sound of Silence). Playback is much improved, but still choppy, as follows:

When CPUs are busy like this, sound is good (not perfect, but much improved):

When CPU activity drops like this, then audio stuttering comes back in full force:

This is the theory behind SpeedKeeper. When SpeedKeeper is running, CPU activity looks like this, but audio is significantly improved (not perfect, but significantly better):

mariettosun · Nov 16, 2022

during high load you should try to see in terminal if some TSC values change compared in idle situation (with usual grep command)

mariettosun · Nov 16, 2022

I do not know if it is available a real time monitor to check TSC values..to see when audio is crappy what happens... but maybe it is unrelated

ExtremeXT · Nov 16, 2022

CaseySJ said:
I am currently booted up with cpus=4 and playing my favorite YouTube music video (Disturbed's Sound of Silence). Playback is much improved, but still choppy, as follows:

When CPUs are busy like this, sound is good (not perfect, but much improved):
View attachment 8348
When CPU activity drops like this, then audio stuttering comes back in full force:
View attachment 8350
This is the theory behind SpeedKeeper. When SpeedKeeper is running, CPU activity looks like this, but audio is significantly improved (not perfect, but significantly better):

View attachment 8353

Try disabling Core P-States, Cool&Quiet and other power saving features which would make it downclock. Do a backup of your BIOS settings before this.

CaseySJ · Nov 16, 2022

mariettosun said:
during high load you should try to see in terminal if some TSC values change compared in idle situation (with usual grep command)

mariettosun said:
I do not know if it is available a real time monitor to check TSC values..to see when audio is crappy what happens... but maybe it is unrelated

The command...

Bash:

sysctl -a | grep -e tsc -e freq

...shows the same values when invoked repeatedly:

Bash:

% sysctl -a | grep -e tsc -e freq

kern.hv.clock.tsc_base: 241525761840
kern.hv.clock.tsc_clock_last: 0
net.link.fake.switch_mode_frequency: 10
net.pktsched.netem.heap_size: 2048
net.pktsched.netem.sched_output_ival_ms: 1
net.pktsched.verbose: 0
hw.busfrequency: 408000000
hw.busfrequency_min: 408000000
hw.busfrequency_max: 408000000
hw.cpufrequency: 4500000000
hw.cpufrequency_min: 4500000000
hw.cpufrequency_max: 4500000000
hw.tbfrequency: 1000000000
machdep.tsc.nanotime.tsc_base: 223238618325
machdep.tsc.nanotime.ns_base: 0
machdep.tsc.nanotime.scale: 954435759
machdep.tsc.nanotime.shift: 0
machdep.tsc.nanotime.generation: 2
machdep.tsc.frequency: 4500006684
machdep.tsc.deep_idle_rebase: 1
machdep.tsc.at_boot: 0
machdep.tsc.rebase_abs_time: 49608508072
machdep.cpu.tsc_ccc.numerator: 0
machdep.cpu.tsc_ccc.denominator: 0

CaseySJ · Nov 16, 2022

It seems that changing FSBFrequency and initialTSC in OpenCore does not change the values we see here. These are after changing FSB to 200,000,000 and TSC to 6,000,000,000.

Bash:

% sysctl -a | grep -e tsc -e freq

kern.hv.clock.tsc_base: 234469918485
kern.hv.clock.tsc_clock_last: 0
net.link.fake.switch_mode_frequency: 10
net.pktsched.netem.heap_size: 2048
net.pktsched.netem.sched_output_ival_ms: 1
net.pktsched.verbose: 0
hw.busfrequency: 408000000
hw.busfrequency_min: 408000000
hw.busfrequency_max: 408000000
hw.cpufrequency: 4500000000
hw.cpufrequency_min: 4500000000
hw.cpufrequency_max: 4500000000
hw.tbfrequency: 1000000000
machdep.tsc.nanotime.tsc_base: 212930989155
machdep.tsc.nanotime.ns_base: 0
machdep.tsc.nanotime.scale: 954436207
machdep.tsc.nanotime.shift: 0
machdep.tsc.nanotime.generation: 2
machdep.tsc.frequency: 4500004571
machdep.tsc.deep_idle_rebase: 1
machdep.tsc.at_boot: 0
machdep.tsc.rebase_abs_time: 47317949425
machdep.cpu.tsc_ccc.numerator: 0
machdep.cpu.tsc_ccc.denominator: 0

ExtremeXT · Nov 16, 2022

@CaseySJ Try this for the I225-V.
Note: Your ACPI path for the SSDT will 99% be different on AMD.

CaseySJ · Nov 16, 2022

ExtremeXT said:
@CaseySJ Try this for the I225-V.
Note: Your ACPI path for the SSDT will 99% be different on AMD.

Will try this soon. Will also check whether P-states in BIOS can be disabled (for audio issue).

CaseySJ · Nov 16, 2022

ExtremeXT said:
@CaseySJ Try adding AmdTscSync.

GitHub - naveenkrdy/AmdTscSync: Kernel extension to sync TSC across all CPU cores.

Kernel extension to sync TSC across all CPU cores. - naveenkrdy/AmdTscSync

github.com

First try with IOCPUNumber set to 0 then to your CPU's threads minus 1.

Will try this as well.

PoMpIs · Nov 16, 2022

CaseySJ said:
Will try this soon. Will also check whether P-states in BIOS can be disabled (for audio issue).

Disabling the P-states I have tried and it did not solve the audio problem, it was still bad

Ryzen 7000 Testing

Member

Guru

Attachments

Guru

Guru

New member

Guru

Donator

Donator

Guru

Guru

Guru

Guru

Guru

Donator

Guru

Guru

Donator

Guru

Guru

Well-known member

Online statistics

Useful Links

Share this page