smpspeed

In 2023, lidnariq wrote a S-SMP clock speed measurement tool that used the SNES's master clock (a quartz crystal, with a typical accuracy of 30ppm) to measure the frequency of the SNES's audio clock (ceramic resonator, with a typical accuracy of 0.5% 5000pmm).

With this test I could easily measure the audio clock and see it slowly speed up as the console's internals warmed up.

I quickly ran the tests on all of my consoles, taking screen captures every 5 minutes and letting the test run for 25 minutes per console.

• 2/1/3 3-chip Super Famicom (26.1C ambient): 32147Hz cold, 32152Hz after 25 minutes
• 1-chip Super Famicom (26.1C ambient): 32036Hz cold, 32043Hz after 25 minutes
• 1/1/1 Super Famicom (26.2C ambient) : 32080Hz cold, 32090Hz after 25 minutes
• PAL 1-chip SNES (25.4C ambient): 32083Hz cold, 32091Hz after 25 minutes
• 1/1/1 Super Famicom (a with broken PPU, 26.2C ambient): 32067Hz cold, no warm measurements

In 2025, dwangoAC of the TASBot community asked for participants to run the lidnariq's smpspeed test and submit the results online. I reran the tests, this time taking screen captures every minute and running the test for 90 minutes (I had read a few reports that it can take an hour the S-SMP to hit max frequency).

Unfortunately, I wasn't able to OCR the screen captures. The various OCR programs in the Debian repositories were unable to reliably read the 0 (misread as 6 or 8), 4 (sometimes misread as 9) or 2 (misread as Z) tiles.

smpspeed-usb2snes.py

If I couldn't automatically get the data from the screenshots, I'll have to try another way. Luckily I had experience in using a usb2snes websocket to read console memory from creating my unnamed-snes-game resources-over-usb2snes subsystem.

I wrote a quick and simple script to read the values out of the VRAM¹ tilemap using usb2snes while the console is running. To ensure the tilemap is read correctly (as there's no way to prevent the usb2snes from reading VRAM at the same time the S-CPU writes to VRAM), the tilemap is repeatedly read until there are 3 identical reads in a row. The test data is then extracted from the tilemap and output as a CSV line.

By default, the script reads every 5 seconds and I let the script run for 2 hours or more on all of my working consoles.

"Time", "SNES PPU", "Meaning", "Slowest", "Fastest", "S-SMP clock", "relative", "Slowest", "Fastest", "DSP sample rate"
2025-03-03T12:30:26.355847, "Connected to SD2SNES ttyACM0"
[...]
2025-03-03T12:40:26.466550, 60, 384587, 384639, 384584, 1025418, +01384, 1025280, 1025426, 32044
2025-03-03T12:40:31.462837, 60, 384587, 384639, 384584, 1025418, +01384, 1025280, 1025426, 32044
2025-03-03T12:40:36.462517, 60, 384587, 384639, 384584, 1025418, +01384, 1025280, 1025426, 32044
2025-03-03T12:40:41.462553, 60, 384587, 384639, 384584, 1025418, +01384, 1025280, 1025426, 32044
2025-03-03T12:40:46.462542, 60, 384584, 384639, 384584, 1025426, +01392, 1025280, 1025426, 32044
2025-03-03T12:40:51.554549, 60, 384587, 384639, 384584, 1025418, +01384, 1025280, 1025426, 32044
2025-03-03T12:40:56.466553, 60, 384581, 384639, 384581, 1025434, +01400, 1025280, 1025434, 32044
2025-03-03T12:41:01.550551, 60, 384584, 384639, 384581, 1025426, +01392, 1025280, 1025434, 32044
 

This python script is MIT Licensed and avaiable on GitHub: https://github.com/TASBotL3C/smpspeed-usb2snes

Analysing the data

Console	Ambient temperature	Minimum DSP sample rate	Maximum DSP sample rate		Sample rate increase	Minimum SR after max SR	Sample rate drift
2/1/3 Super Famicom	29.2C - 31.1C	32147.06Hz	32155.78Hz	1:14:59	8.72Hz	32155.03Hz	0.75Hz
1/1/1 Super Famicom	30.8C - 31.9C	32084.91Hz	32098.16Hz	1:27:10	13.25Hz	32096.94Hz	1.22Hz
PAL 1-CHIP	29.8C - 30.0C	32086.88Hz	32095.38Hz	0:49:04	8.50Hz	32094.62Hz	0.75Hz
1-CHIP Super Famicom	31.2C - 31.9C	32040.00Hz	32047.69Hz	1:10:40	7.69Hz	32046.97Hz	0.72Hz

All four of my consoles have different DSP sample rates with similar-ish values as the 2023 tests. The differences in the 2023 and 2025 results could be explained by the different ambient temperatures. I will need to rerun the smpspeed tests when the cold seasons start to do a proper comparison.

The DSP sample rates are not stable and do drift a little as the ambient temperature and internal temperature changes.

More importantly, the DSP sample rate increase from cold to warm is an average 9.54Hz across my 4 consoles and significantly smaller than the variance between consoles. This is also reflected in the TASBot data, where the cold to warm increase is an average 8Hz while the console variance is 217Hz (31965Hz to 32182Hz).

I noticed the temperature dropping as the sun was slowly setting and left my 1/1/1 Super Famicom console running for 4 hours. The temperature did not drop much, but the S-SMP clock and DSP sample rate slowly decreased as my room got colder.

Finally, I manually transcribed my 2023 screenshots and compared it to the 2025 data. The 2023 sample-rates are slightly lower than the 2025 measurements. This could be explained by the colder temperatures.

Why is this important?

As someone who has just created a homebrew SNES audio driver, there are 3 design considerations when designing an APUIO communications protocol:

1. APU IO communication occurs across 8 unbuffered ports (4 S-CPU -> S-SMP and 4 S-SMP -> S-CPU)
2. If a port is read at the same time it is written the data read is corrupted
3. There are no interrupts in the S-SMP

To synchronise a data transfer or command from the 65816 to S-SMP some kind of semaphore signalling² is typically used to:

• Ensure that the S-SMP has finished processing the previous data/command before the S-CPU can safely write to the APUIO ports to send a new command
• Signal to the S-SMP that there's a new data/command and the APUIO ports can be safely read

How this is done varies across games.

The Terrific Audio Driver (TAD) API is asynchronous - the main-loop writes a pending command to a queue and on the next Tad_Process call (which should be called once per frame) checks if it's OK to send a new command. In TAD there are 2 main queues, one for commands (pause, play, set-song-timer, etc) and another for sound effects. The TAD S-SMP code is designed to check and process IO commands a minimum of 125 times a second. It is possible for the audio-driver to lag and delay an IO command for a single frame. If the game-code waits until a command can be queued before advancing to the next state, that action could be delayed, depending on audio-lag and DSP sample rate.

The second most common command (after play-sound-effects) is the switch-to-loader command, required to load a new song into the Audio-RAM. The game immediately sends a switch-to-loader command and on the next Tad_Process it checks if the audio-driver has sent a "loader-active" signal before transmitting song data. Since there are no interrupts, the audio-driver can only check for a switch-to-loader command after it has finished processing music and sound effects (there's a few more checks in TAD but let's ignore them here). On one console this might take 0.126 frames to process the music-tick, on a different console it might take 0.127 frames. It might not seam like much but it is enough to potentially delay the start of song loading by 1 frame (depending on timing, lag and game-code).

Then there's audio-data loading. To ensure there is no data loss, games typically transmit 1 - 3 bytes at a time (depending on the loader) and wait for an acknowledgement from the S-SMP before sending more data. The TAD loader transmits 2 bytes at a time with a transfer rate of 847 - 855 bytes per second (faster than IPL's 678 - 685) depending on the DSP sample rate. By default the TAD API transfers 256 bytes per frame, freeing CPU time for a fade-in or loading animation. However, snesdevs can choose to ignore this and upload the whole song in one go. If they choose to bypass background loading the audio-data loading time is unknown.

Finally, I need to talk about auto-joypad read. This feature of the SNES automatically reads the controller at (roughly) the start of every Vertical-Blank. It is done in the background and has no understanding of lag-frames. If auto-joypad read is on while loading a song, the console might request 5 controller reads on one console or 4 controller reads on different console with a faster DSP clock.

The unknown audio loading time is worse in games that upload new audio samples when loading a new song. In TAD (which does not sample swap) a song might be 3-7KiB. A game with sample swapping could easily transfer 20KiB or more of audio data when loading a song.

TAD does not allow game code to query the song or sound effect state. Some games do. A game which waits until a sound effect has finished before doing the next action can also cause a TAS desync.

Simulating IPL loader speeds

I wrote a simple test ROM that uses the S-SMP's IPL (Initial Program Load) ROM to transfer 32KiB of data to the Audio-RAM. I then used Mesen to simulate a wide variety of DSP sample rates and the Mesen Profiler to measure the loader's speed (excluding initialisation and waiting for IPL).

The IPL loading speed is bottlenecked by the speed of the S-SMP audio processor, not the S-CPU (there is very little difference between FastROM vs SlowROM speeds).

Transferring 32768 bytes via IPL on a simulated NTSC console
DSP sample rate	SlowROM			FastROM
	m-cycles	time	bytes/frame	m-cycles	time	bytes/frame
31900Hz	17252854	803.31ms	678.74	17251878	803.26ms	678.78
31920Hz	17242394	802.82ms	679.15	17241100	802.76ms	679.20
31940Hz	17230890	802.28ms	679.61	17230280	802.26ms	679.63
31960Hz	17219862	801.77ms	680.04	17219542	801.76ms	680.05
31980Hz	17209136	801.27ms	680.47	17208722	801.25ms	680.48
32000Hz	17198574	800.78ms	680.88	17197986	800.75ms	680.91
32020Hz	17187642	800.27ms	681.32	17187250	800.25ms	681.33
32040Hz	17177330	799.79ms	681.73	17176514	799.75ms	681.76
32060Hz	17167442	799.33ms	682.12	17165820	799.26ms	682.18
32080Hz	17156204	798.81ms	682.57	17155126	798.76ms	682.61
32100Hz	17145252	798.30ms	683.00	17144420	798.26ms	683.03
32120Hz	17134988	797.82ms	683.41	17133766	797.76ms	683.46
32140Hz	17123910	797.30ms	683.85	17123114	797.27ms	683.88
32160Hz	17113906	796.84ms	684.25	17112420	796.77ms	684.31
32180Hz	17102618	796.31ms	684.70	17101768	796.27ms	684.74
32200Hz	17091528	795.80ms	685.15	17091158	795.78ms	685.16

To verify these numbers I ran the test on two of my consoles. The output of the ipl-speed-test is:

1. Test number
2. Number of Vertical Blanks encountered
3. Amount of free CPU time until the next Vertical Blank (via spinloop counting); on an NTSC system, the maximum spinloop count is 0x1B17

A quick bit of math³ gives the following IPL loading speeds (these numbers include the loader setup):

• 1-CHIP SFC (~32038Hz DSP sample rate): 48.1 frames, 799.9ms
• 3-CHIP SFC (~32147Hz DSP sample rate): 47.9 frames, 797.1ms

Which is consistent with the simulated loader times above.

Simulating the TAD loader speeds

I also simulated the Terrific Audio Driver loader speeds for various DSP sample rates. It is 24.8% faster than the IPL.

The IPL transfers 1 byte at a time as it is designed to fit in a tiny 64 byte ROM. The TAD loader is 116 bytes, transfers 2 bytes at a time, and also manages the common-audio-data and song-data memory addresses.

This table was created by bypassing the TAD API bytes/transfer frame limits, transferring 32KiB in one go and measuring the TadPrivate_Loader_TransferData execution time using the Mesen Profiler.

Transferring 32768 bytes via the Terrific Audio Driver loader on a simulated NTSC console
DSP sample rate	SlowROM			FastROM
	m-cycles	time	bytes/frame	m-cycles	time	bytes/frame
31900Hz	13821380	643.54ms	847.26	13820958	643.52ms	847.28
31920Hz	13812564	643.12ms	847.80	13812478	643.12ms	847.80
31940Hz	13804008	642.73ms	848.32	13803810	642.72ms	848.33
31960Hz	13795408	642.33ms	848.85	13794998	642.31ms	848.88
31980Hz	13786768	641.92ms	849.38	13786590	641.92ms	849.39
32000Hz	13778168	641.52ms	849.91	13777814	641.51ms	849.93
32020Hz	13769524	641.12ms	850.45	13769330	641.11ms	850.46
32040Hz	13760840	640.72ms	850.98	13760738	640.71ms	850.99
32060Hz	13752412	640.32ms	851.50	13751998	640.30ms	851.53
32080Hz	13743816	639.92ms	852.04	13743550	639.91ms	852.05
32100Hz	13735216	639.52ms	852.57	13734994	639.51ms	852.58
32120Hz	13726660	639.12ms	853.10	13726398	639.11ms	853.12
32140Hz	13718152	638.73ms	853.63	13717914	638.72ms	853.65
32160Hz	13709552	638.33ms	854.17	13709394	638.32ms	854.18
32180Hz	13701000	637.93ms	854.70	13700838	637.92ms	854.71
32200Hz	13692616	637.54ms	855.22	13692390	637.53ms	855.24

What does this mean for TAS hardware verification?

It truly depends on the game. There's a potential 10000-60000 CPU/SMP synchronisations loading the audio driver, music data and BRR samples into Audio-RAM when the game starts up. Each one adds a tiny amount of variance to the game's load time. If automatic-joypad-read is on and the number of loading frames in the TAS-emulator does not match the number of loading frames on hardware, the TAS playback desyncs.

In my opinion, for a game to not TAS-desync (after the initial audio-data load) the game would need to load everything to Audio-RAM at the start, send APU commands at most once per frame, not delay actions waiting for APU acknowledgement, and process the song/sound-effects without audio-lag. (And even then I'm unsure if it a 30 minute TAS would desync or not. I'm a snesdever, not a TASer or hardware-guy.)

However, most SNES games do not do this. Not even imaginary Terrific Audio Driver games. Games can load song data whenever the song changes to free up Audio-RAM for more samples. They can also swap out samples when loading songs to improve Audio-RAM utilisation. Each load adds 1 large and 2000-40000 tiny CPU/SMP synchronisations, depending on data size and loader protocol. Each one increases the risk of crossing a frame boundary and causing a TAS desync between hardware and emulator.

What does this mean for speedrunners?

Again, it depends on the game. It the depends on:

• The audio driver's APUIO protocol
• The speed of the loader
• How often the audio driver checks for a new command
• What the game does when a command has not been acknowledged (Is it dropped? Does the game try again on the next frame? Does the game wait until acknowledgement?)
• The tempo of the current song

Song loading delay

It's not all doom and gloom. The differences in loading times are small.

Let's take another look at the IPL loading speed, this time measuring the difference in loading speeds.

DSP sample rate	FastROM time	Delta	DSP sample rate	FastROM time	Delta
31900Hz	803.26ms		32060Hz	799.26ms	0.49ms
31920Hz	802.76ms	0.50ms	32080Hz	798.76ms	0.50ms
31940Hz	802.26ms	0.50ms	32100Hz	798.26ms	0.50ms
31960Hz	801.76ms	0.50ms	32120Hz	797.76ms	0.50ms
31980Hz	801.25ms	0.51ms	32140Hz	797.27ms	0.49ms
32000Hz	800.75ms	0.50ms	32160Hz	796.77ms	0.50ms
32020Hz	800.25ms	0.50ms	32180Hz	796.27ms	0.50ms
32040Hz	799.75ms	0.50ms	32200Hz	795.78ms	0.49ms

Assuming a warm console has a DSP that runs 20Hz faster (which seams unlikely given the average cold/warm increase in the data collected is 8Hz), it will be half a millisecond faster loading 32KiB of audio data. Even then, the difference between a theoretical 31900Hz and 32200Hz DSP sample rate is 7.8ms, less than a half a frame. I suspect when the audio data loader starts (within the frame), the size of the data and what the game does after the loader have a bigger impact on lag-frames then IPL loading-times.

Switch-to-loader delay

Do not assume a faster S-SMP clock is better. The time it takes for the audio driver to process a song-tick can be greater and more unpredictable than the difference between cold and warm loading times.

Here's a hypothetical switch-to-loader command on a song running at ~100 ticks/second. In this example, the S-CPU sends the switch-to-loader command after the song has been playing for 5 minutes and the audio-driver checks the APUIO ports once per tick.

The difference in tick lengths for the various S-SMP clocks is tiny, measured in microseconds, but quickly add up when multiplied by the tens of thousands (or hundreds of thousands) of song ticks.

After a few minutes the unavoidable S-SMP clock drift (as the ceramic resonator's frequency fluctuates with temperature) will cause the song's position to be effectively unknowable. This unpredictability results in a random delay based on the song's tick timer - less than 10ms for a song with a 100 ticks/second timer and <25ms for a song with a slow 40 ticks/second timer.

Here's the same timing diagram, except it covers a tiny 1.75Hz sample-rate range. The switch-to-loader delay is all over the place, 0.5ms - 9.9ms.

A different audio-driver (like TAD) might repeatedly check the APUIO ports for new commands whenever the driver is not processing audio. Assuming each tick uses the same amount of processing time⁴ we get the following timing diagram:

Most of the time the audio-driver switches to the audio-data loader near instantly. Sometimes the switch-to-loader command is sent when the audio-driver is processing the song which causes an unpredictable delay, but it is a lot smaller than audio-drivers that process commands once per tick.

Remember this is only an analogy. The actual switch-to-loader delay depends on a lot of complex factors including the audio-driver, the song timer, song position, song complexity, song effects and sound effects.

How this affects the game also depends on how the game communicates with the audio-driver. A game that loads the level data in the following order:

• Send a switch-to-loader APUIO command
• Decompress level data to Work-RAM
• Decompress graphics data to Work-RAM
• Transfer graphics data to VRAM
• Wait for the S-SMP to acknowledge the switch-to-loader command
• Transfer audio data to the loader

Would be practically immune to the variable switch-to-loader delay if it took more than 2 frames to decompress the level data.

Conclusions

A SNES console's audio module runs on a separate clock to the console's S-CPU and S-PPU chips. This was probably done to simplify the audio module's development and ensure NTSC and PAL consoles (which have different master-clock frequencies) output audio at the same pitch and ~32000Hz sample rate.

All of my consoles have wildly different S-SMP clocks and process sound at different sample rates. While my 3-chip SFC conosole is running faster than the rest, they are all within the ±0.5% (5000pmm) tolerance of a typical ceramic resonator.

The ceramic resonator's frequency varies across consoles and fluctuates with temperature, causing unpredictable synchronisation delays when a console's S-CPU communicates with the external audio module's S-SMP processor, leading to desyncs when replaying a TAS on original hardware.

I'm unable to make a definitive statement on what this means for speedrunners. The S-SMP clock speed impact is minimal but it depends on the game's audio-driver and how the game communicates with the audio driver.

Special Thanks

I would like to thank:

• lidnariq for creating the S-SMP clock speed measurement tool
• dwangoAC and the TASBot community for spreading the word about smpspeed to and collecting the interesting data
• Sour for creating Mesen
• RedGuy for creating usb2snes
• Sylvain "Skarsnik" Colinet for creating QUsb2Snes