Ryzen 7000 Testing

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:

apps.apple.com

Code of War: Shooting Games App - App Store

Download Code of War: Shooting Games by XDEVS LTD on the App Store. See screenshots, ratings and reviews, user tips and more games like Code of War: Shooting…
apps.apple.com 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 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.
Click to expand...
@ExtremeXT,

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

An extract:

Core Speed5497.0 MHz
Multiplier x Bus Speed55.0 x 99.9 MHz
Base frequency (cores)99.9 MHz
Base frequency (mem.)100.0 MHz
Instructions setsMMX (+), SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, SSE4A, x86-64, AMD-V, AES, AVX, AVX2, AVX512F, FMA3, SHA
Microcode Revision0xA601203
L1 Data cache8 x 32 KB (8-way, 64-byte line)
L1 Instruction cache8 x 32 KB (8-way, 64-byte line)
L2 cache8 x 1024 KB (8-way, 64-byte line)
L3 cache32 MB (16-way, 64-byte line)
Max CPUID level00000010h
Max CPUID ext. level80000028h
FID/VID Controlyes
# of P-States2
P-StateFID 0x8B4 - VID 0xC9 (45.00x - 1.256 V)
P-StateFID 0x878 - VID 0x79 (30.00x - 0.756 V)
PStateReg0x80000000-0x4B7248B4
PStateReg0x80000000-0x479E4878
PStateReg0x00000000-0x00000000
PStateReg0x00000000-0x00000000
PStateReg0x00000000-0x00000000
PStateReg0x00000000-0x00000000
PStateReg0x00000000-0x00000000
PStateReg0x00000000-0x00000000
 

Attachments

Last edited:
  • Like
Reactions: ExtremeXT
And here is HWINFO64...

HWInfo64 - Asus Gene.png
HWInfo64-Processor.png
 
Last edited:
  • Wow
Reactions: Galve2000
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-StateFID 0x8B4 - VID 0xC9 (45.00x - 1.256 V)
P-StateFID 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):
PStateReg0x80000000-0x4B7248B4
PStateReg0x80000000-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):
Screenshot 2022-11-15 at 6.14.53 PM.png
 
Last edited:
  • Like
Reactions: craighazan, etorix and ExtremeXT
Hi everyone,
With the progress reported here, am I correct in my understanding that an external DAC wouldn’t have audio issues?
 
Jaraheel said:
Hi everyone,
With the progress reported here, am I correct in my understanding that an external DAC wouldn’t have audio issues?
Click to expand...
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.
 
  • Like
Reactions: tomnic and ExtremeXT
the external DAC must have it's own timer to avoid the sound issues.
 
  • Like
Reactions: tomnic, fabiosun, etorix and 1 other person
  • Like
Reactions: CaseySJ
@CaseySJ could you try to limit your cpu cores as I do in this picture

1668591548846.png

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)
 
  • Like
Reactions: CaseySJ, ExtremeXT and tomnic
Aluveitie said:
the external DAC must have it's own timer to avoid the sound issues.
Click to expand...
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
 
Last edited:
  • Like
Reactions: Jaraheel and ExtremeXT
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)
Click to expand...
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):
Screenshot 2022-11-16 at 3.07.53 AM.png
When CPU activity drops like this, then audio stuttering comes back in full force:
Screenshot 2022-11-16 at 3.12.03 AM.png
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):

Screenshot 2022-11-16 at 3.15.05 AM.png
 
  • Like
Reactions: ExtremeXT and fabiosun
during high load you should try to see in terminal if some TSC values change compared in idle situation (with usual grep command)
 
  • Like
Reactions: ExtremeXT
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
 
  • Like
Reactions: ExtremeXT
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
Click to expand...
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.
 
  • Like
Reactions: etorix
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)
Click to expand...

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
Click to expand...
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
 
  • Like
Reactions: ExtremeXT and fabiosun
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
 
  • Like
Reactions: etorix and ExtremeXT
@CaseySJ Try this for the I225-V.
Note: Your ACPI path for the SSDT will 99% be different on AMD.
 
  • Like
Reactions: PoMpIs and CaseySJ
ExtremeXT said:
@CaseySJ Try this for the I225-V.
Note: Your ACPI path for the SSDT will 99% be different on AMD.
Click to expand...
Will try this soon. Will also check whether P-states in BIOS can be disabled (for audio issue).
 
  • Like
Reactions: PoMpIs and ExtremeXT
  • Like
Reactions: PoMpIs and ExtremeXT
CaseySJ said:
Will try this soon. Will also check whether P-states in BIOS can be disabled (for audio issue).
Click to expand...

Disabling the P-states I have tried and it did not solve the audio problem, it was still bad 🤷‍♂️
 
You must log in or register to reply here.
Top Bottom
✖
  AdBlock Detected
Sure, ad-blocking software does a great job at blocking ads, but it also blocks some useful and important features of our website. For the best possible site experience please take a moment to disable your AdBlocker.