Nearly all the CPU-intensive activities you cite (except for equalization) are the responsibility of the DAC.
Um, what?? Depends. In my world, a DAC takes S/PDIF in, or USB in, and produces an analog signal out.
While upsampling may be done by the DAC, file filtering and streaming does not. Many manufacturers may chose to implement their own upsampling algorithms before the DAC.
I’d also like to point out that the latency issue you raised does not affect sound quality but the time it takes after pressing Play until the music starts.
You misunderstand how I meant latency. I did not mean latency to user input, I meant the time between a CPU starting to process a sample and the time it is done with it, also known as CPU time. In order to do any processing a CPU takes time. We can estimate the worst case boundaries. For a 44.1kHz signal, the CPU must complete all of it’s work in 1/44,100 of a second, and have that sample of data ready for the DAC. If the signal is a higher sample, or is being upsampled, the CPU must complete it’s work in 1/88200 of a second for an 88.2kHz sample/upsample.
That’s’ about 11 microseconds. That’s the absolute maximum amount of time the CPU is allowed to handle this, or else the output will not keep up with the input. It must do at least the format conversion, EQ and upsampling. This is in addition to any network housekeeping, and UI interactions, and in addition to responding to the DAC clock saying "Gimme the next one!"
So, if a CPU core takes EXACTLY 11 microseconds to process this sample, it has ZERO time to process anything else. It has no time for network / house keeping, library management or UI responding. Any additional work would get queued and the audio output would stall.
If the CPU takes 11/2 usecs (microseconds), then the CPU core is only 50% utilized, and has processing power to schedule other work.
It’s important to stress that you must have input/output flow balance. That is, the rate of processing must be equal to or faster than the rate of output. You can’t make up for this with longer delay before a track starts, or larger buffer sizes, unless they are infinitely large. Imagine a CPU that takes 22 uSeconds to process an 88 kHz sample, and that the track is 5 minutes long. That means that the CPU won’t finish with the last sample for 10 minutes. You’d need a five minute buffer. You press play, wait five minutes until the buffer fills, and then the music starts. 10 minutes after you hit play, the 5 minute track finally finishes playing.
Lastly, we should of course note that we are talking about a stereo sample. That is, at 88.2 kHz we must complete the decompression, EQ and upsampling of 2 samples every 11 microseconds.
So, if you ask me, how much CPU power do you need?
Well, you need enough CPU power to completely process every sample in real time, plus handle all the additional work.
We can calculate the maximum allowed compute time this way:
seconds = 1 / sample rate
So, you must use a CPU capable of meeting this, AND still have enough power to handle the other events that are happening in semi-real time. This calculation provides the minimum boundary.
Of course, for many reasons, having the CPU take 100% is not a good thing in an interactive or RTOS, so a target of 50% CPU utilization in an embedded CPU is reasonable. The amount of CPU power, if we think of this in terms of MIPS or SPECints or FLOPS is therefore dependent on the work that must be done in real time. You do less work, you get a cheaper, slower CPU.
I don’t really think it’s "a lot" either. I mean, we live at a time when 8 GByte/4 core 64-bit ARM based Raspberry PI sell for $120 and are fully capable of handling a desktop PC. It is important however to note that unless you know the architecture, clock speed, clocks and threads you don’t really know much about "how much" compute power you have. You can’t say "well I have 4 cores, so I can run grand theft auto." The’re all small, rectangular, and have a lot of pins on them. That doesn’t make them interchangeable in terms of the work they can do per unit time.
For instance, your average router has a pretty beefy, multicore Broadcomm system on a chip (including CPU) in it too, and all it’s doing is moving packets around. Is it "too much"? I doubt it.
Best,E
