Current time & speed have no meaning to processing recordings of past signals. The recording itself has timing info.
The performance limits on processing signals are CPU number-crunching and/or how fast the CPU can read that data from memory, disk, network, or wherever it's coming from. For audio, often that's much faster than 1 signal-second per wall-clock-second, but you certainly can run an inefficient and/or computationally-intensive algorithm on an ancient slow computer and only go at 1 signal-second per minute, and get the identical output file to running on a modern CPU at 10 signal-seconds per second.
If that source is an analog->digital converter that's converting a mic input in real-time, that's what sets the speed limit to 1 signal-second per real-world second1, not the CPU itself.
The key concept is that the passage of real-world wall-clock time has zero meaning or relevance to how a computer processes digitally sampled audio data; the data comes with its own timing information.
It's often useful to be able to do something at least as fast as real-time, meaning you can keep up with the outside world instead of having to save it to disk and process offline, but other than that you're just doing math on the samples from time
Analogy: looking at printouts of weather records
If you have some printouts of weather records from the past 7 days, how can you recognize recognize freeze and thaw cycles, and shifting wind patterns, if you turn the pages and read faster than 1 day of data per real-time day? The obvious answer is "what? Why would I have to read that slow, and what does that even have to do with analyzing recorded data?" That's exactly the case for a computer doing any kind of processing on recorded signals of any kind (video, audio, key-stroke records from a keyboard keylogger, etc.)
Computers don't "experience" recorded audio in any way other than looking at the digital samples. For us, seeing lists of numbers would be meaningless. Same for computers; they don't truly understand anything. (Just like you don't feel cold or hot from looking at a table of past temperatures.)
If you program a set of steps to follow, they will do so. It's up to programmers to find useful sets of steps to make computers run on audio data. If that set of steps happens to have a useful result then running it to get that result can be useful. Like finding the peak sample value over some interval, normalizing the volume, filtering out some frequency range, or something more complex like outputting a sequence of text characters (speech->text), or a compressed representation of the audio (e.g. mp3, AAC, Opus, or FLAC).
At no point do any of this "mean" anything to the computer. It's all just numbers that represent sound, but the CPU itself doesn't know or care what they represent. It's just doing addition, multiplication, compare+branch to run different code depending on the data, and stuff like that. (i.e. running machine code, with numbers in registers and memory).
Speech-recognition is just a special case of what you can do to analyze a signal. It's not fundamentally different from compressing the audio file into a
.opus, as far as the CPU and OS are concerned. Obviously the algorithms you'd use are much different, but nothing in them depends on real-time, CPU frequency, or whatever, and will give the same result no matter how fast or slow the CPU is.
I assume you understand that the faster your computer, the faster it can ZIP a hundred megs of data, but you still get the exact same output file. This is totally normal, right? Speech->text or other audio or video processing is the same.
All the file formats contain timing information (or you supply that separately). In most files (like simple
.wav) there isn't a separate explicit timestamp stored for each sample, but there is one piece of metadata for the whole file that tells you the sample rate was (for example) 48kHz, so the computer knows that every 48,000 samples make up one second of recorded time. That's equivalent, and lets the computer know what time each part of the audio recording corresponds to.
It makes zero difference how slow or fast the computer is. e.g. you could run an audio processing program on a computer from 20 to 40 years ago (assuming it could load enough of it into RAM to run your algorithm at all), and it might take hours or days to do something to 2 minutes of audio, vs. 10 seconds for a modern computer.
The number-crunching speed vs. real-time, processing time vs. signal time, is just the performance number. It's not fundamentally different from timing how long it takes to
zstd) compress a file: you can report the results as seconds per input megabyte. With audio and video input files, you could measure the input size in samples, or uncompressed-bytes, and report the speed in MB of audio crunched per second. Or you can measure in time and report a ratio of how fast you processed vs. real-time. e.g. audio compressors often report the speed they achieved as a ratio of signal-time / processing-time. i.e. how much faster or slower they were than playback at 1x.
If you run a benchmark on a video game, often you'll see the frames fly by at crazy high speed. (Or very low). Depending on the game, it's simulating game-time much faster than normal, because you told it to benchmark so it doesn't limit its speed to 1 game-second per real-second. It's simulating more than 1 game-second of game-time per real-second. If a car in the game goes off a jump and is in the air for 90 frames (1.5 game seconds at a standard 60Hz), that would still be true regardless of how fast or slow the benchmark was running. (Real games usually don't have their simulation time based on a fixed frame-rate, not since old 2d days, but pretend you had a simple game engine that always had to run at 60Hz to do real-time.)
For more about digital sampling, see Monty Montgomery's digital sampling show-and-tell 25 min video lecture / demo, and part2. The motivation was to explain why 96kHz / 24-bit audio is not perceptibly better than standard 44.1kHz / 16-bit, especially if correctly dithered, but it's a great intro from scratch to digital sampling concepts. (Monty famously developed the Ogg/Vorbis open-source audio codec and contributed to Opus, the current best quality audio compressor.) He even uses some real physical oscilloscopes including an analogue one in the demo, showing signals turning into digital and back to analogue, to prove that digital sampling works.
Seeing that signals can turn into a sequence of numbers may help understand how computers can process them.
(Of course this is all done with real-time processing, so IDK if it will help you grok the concept that time has no meaning for signal processing unless you're specifically doing real-time processing where real-now = signal-now.)
Footnote 1: It will take less than 1 CPU-second to process that second of audio data, so the CPU can spend some time in low-power sleep while it waits for more data to build up in a buffer. Otherwise your CPU will sometimes get behind and drop parts of the audio input to catch up, or simply just get behind, depending on the design of the software that manages input and output in a real-time or offline style.
If you care about real-time usage, you want the CPU to be faster so that even in the worst case, it doesn't fall behind real-time. (And also, your algorithm has to be designed not to need "look-ahead" at future parts of the signal. In a real-time use case, you can't get access to those without buffering for as many seconds as you want to look ahead.) Other than that, there's no fundamental difference (in terms of how the CPU works) between running signal processing in real-time vs. offline on already-recorded files.
I know you didn't ask about real-time processing, but it's interesting to note that the major difference between real-time vs. offline signal processing is that real-time introduces the possibility of the CPU "getting too far behind" in processing, if you try to make it run slow code. This maybe helps make clear that unlike a human brain, it always takes as much CPU time as it needs per second of signal, not processing differently depending on speed.
(You could write a program that switches to a simpler faster algorithm when it's getting behind, but that's not what I mean.)