Is the lag inherent to the protocol, or just a matter of poor receiver implementation?
In that setting, nobody's going to say, "Hey, let's just pop this radio into our cars, live with it for a few weeks, and then figure out where we need to go next." It's too late. Instead I think the thing to do is force convergence early and often in the product timeline, so that the supposedly-little things like this have plenty of time to get noticed and fixed.
A good example of this is Apple. I'm told that in consumer electronics the typical number of iterations with physical prototypes is 3-7. For the first iPod, Apple went through more than 100. The difference was enough for them to crush the competition so thoroughly that people these days are surprised to hear that there were MP3 players before the iPod (and smartphones before the iPhone).
...which is actually quite suitable for the safety-critical parts of a car like the ECU and other controllers that control the actual driving aspect, but not for everything else that doesn't need such a level of process.
On the other hand, I suppose it could also be blamed on the lack of "performance is a feature" --- if they specified the radio to be as responsive as the accelerator and brake, for example.
I do think short-cycle methods have some intrinsic advantages, though. By making critical functionality available much earlier for testing, you get more time and more chances to make sure it's really safe. If early versions are bad, you get early warning signs that aren't available in a Waterfall process. And if testing turns up issues early on, it's much cheaper to make fundamental architectural changes: less code to change and more time to change it in. And Waterfall processes aren't at good at dealing with unknown unknowns; some things you only learn by trying them out.
Maybe it's the whole "let's run Linux on it because we can" phenomenon. The microcontrollers in the old electronic radios didn't run an OS but interacted with the hardware directly. The number of instructions executed from sensing the dial change to updating the tuner and display would probably be less than 100. Now it's half a dozen layers of abstraction and millions of instructions to do the same thing, on a processor which is maybe "only" 1000x faster at most...
Or am I totally misreading this?
Coupled with a decoder that can manage double the actual frame rate, it should cut the switch time with something like on average 1/4, worst case better than 1/2.
Another source of delay is just the length of audio packets themselves (have to wait for the beginning of one) and radio limitations.
But they're compressed in such a way that doesn't require any previous frame. It's compressed like a picture would be.
The sad part is that HD Radio is actually startlingly better on AM, while FM is an incremental improvement. But few AM stations use HD because most AM stations operate on a shoestring, and it ruins your fringe coverage.
But when you find an AM station that's in HD and you hear the receiver switch from analog to digital -- holy cow!
At a guess the critical number is "The transmitted signal has a frame structure of 96 ms duration (Transmission mode I)", which implies that most systems will need to buffer at least that much and probably several times that.
Theoretically you could decode all the signals in a particular DAB multiplex at the same time (e.g. all the BBC stations are on the same multiplex in the UK), and then change instantly between them, but I don't think consumer recievers let you do this. Might be able to try it with SDR.
I guess an optimization the receivers could do is decode all the presets, then at least switching between those would be instant.
I would speculate that it's because it's fairly close to 100 and is also divisible by a fairly high power of 2 (32). Buffer management is easier (less arithmetic) when using powers of 2.
I could be completely wrong, but 96 is the kind of number that crops up in computing quite a bit for this reason. Having said that, the number of samples may be more important than the number of milliseconds.
I mean, good point. I dug a bit farther and found this document which discusses the design in some detail:
https://web.archive.org/web/20040919073530/http://www.cs.col...
It looks like MP1 has 32 subbands and works on 12 samples each, which results in a frame size of 384. MP2 works on 3 groups of 12 samples for each subband, resulting in 1152 samples.
Of course this just punts it to the question of why 32, 12, and 3? To which I can only answer: quick, look behind you! <runs away>
At least the mystery numbers are smaller.
But seriously, I'm at (beyond) the limits of my understanding of this stuff, so if anyone with more knowledge would care to chime in and explain those, I'd be most interested to know.