4 ms·

It's probably similar to switching TV channels (which isn't instant anymore either). The receiver needs to wait for a new "key frame" (on that isn't compressed)

It's probably similar to switching TV channels (which isn't instant anymore either). The receiver needs to wait for a new "key frame" (on that isn't compressed) before it can begin displaying/sounding?/outputting the rest of the compressed stream.

yoran 9y ago
True that. I feel like we've really gone backwards on that aspect concerning TV. I remember a time where I could turn on the TV and be 3 channels further all within the space of 2 seconds. Now my "smart" TV takes 5 seconds just for a first paint, and changing a channel once takes a second. You just can't beat the latency of analog circuits!
- Asooka 9y ago
  You mean uncompressed data. Yes, analogue is uncompressed, but digital could also be uncompressed. However, everyone wants to stuff more video, more audio over the link, so we compress... Bandwidth goes up, latency also goes up, and things get more complicated...
  - blattimwind 9y ago
    Analogue video signals are absolutely compressed (interlacing, PAL, NTSC, SECAM). It's just not as efficient as MPEG-X combined with hyper-aggressive modulation schemes and forward-error correction, channel-capacity wise.
- mark-r 9y ago
  My new car has a radio with a touch-screen interface. When I turn the car on there's a space of about 10 seconds where the radio is operating but I can't change the station or volume or even turn it off. It's quite annoying when you were rocking out last time you were in the car and now you have passengers.
  - wpietri 9y ago
    To me this is symptomatic of a long or broken feedback loop in the development process. E.g., a classic waterfall approach where somebody writes a big spec, a team spends a bunch of time implementing, and then sometime at or after the deadline, a working model is produced. 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).
    - userbinator 9y ago
      a classic waterfall approach where somebody writes a big spec, a team spends a bunch of time implementing, and then sometime at or after the deadline, a working model is produced. ...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.
      - wpietri 9y ago
        I think the choice of process is basically orthogonal. Waterfall and Agile processes done well both have been demonstrated to produce safety-critical software. (See, e.g., Nancy van Schooenderwoert's work in medical devices.) Both can produce dangerous software. (E.g., Toyota's "unintended acceleration" issues.) The question is much more about what practices you put in place to assure quality. 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.
- ryandrake 9y ago
  The radios from my various cars throughout the years are just as bad. My 1970s era radio turned on instantly and there was zero delay as I tuned through channels with a nice smooth analog dial. My 1990s era radio took about 500ms from power on to audio output. The "dial" had steps in it though and was not continuous, and there was a noticeable (again probably around 500ms) delay between when 'click' tactile feedback and when the station was successfully tuned. My current car takes 15 seconds just to boot (WTF), and then I have to navigate some horrible menu just to get to the radio controls. It's like these guys are actively trying to make things worse.
  - userbinator 9y ago
    Even the 1980s car radios with digital controls had no perceptible delay, despite containing microcontrollers with a tiny fraction of the speed and memory of the modern ones. 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...
georgeglue1 9y ago
It sounds like you could build a TV/device that caches key frames for all channels on the client/consumer0side. Or am I totally misreading this?
- namibj 9y ago
  For sattelite tv you wouls need to handle over a Gigabit mpeg-2. Not easy.
  - mickronome 9y ago
    Caching without decoding would still be a nice boost, wouldn't it ? 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.
    - jimktrains2 9y ago
      You'd still need the additional tuner(s) to provide the data to cache.
- KSS42 9y ago
  There are set top boxes that have many tuners. The STB uses the extra tuners to anticipate a channel change and tune ahead to the next channel. (Fast Channel switch).
BLanen 9y ago
Audio compression doesn't work that way. It doesn't use keyframes.
- jimktrains2 9y ago
  It has some kind of equivalent from my understanding. MP3 has frames https://en.wikipedia.org/wiki/MP3#File_structure https://en.wikipedia.org/wiki/MP3#File_structure and I'd assume all methods do, otherwise how could you start decompression if you don't have a starting point?
  - TD-Linux 9y ago
    The prediction gain of audio codecs is <1, which basically means that if you start at a random packet, once you play enough packets it'll converge to sound the same as if you had started playing from the beginning. It'll sound bad at the beginning though, so you usually crop off the first bit after seeking (80ms for Opus, much longer for other codecs). Another source of delay is just the length of audio packets themselves (have to wait for the beginning of one) and radio limitations.
  - mortehu 9y ago
    MP3 frames are all full frames, whereas a key frame is a full frame that is followed by incremental updates.
danmaz74 9y ago
Technical detail: for video, key frames are compressed. And this technique isn't used for audio.
- jimktrains2 9y ago
  > for video, key frames are compressed But they're compressed in such a way that doesn't require any previous frame. It's compressed like a picture would be.

yoran 9y ago

True that. I feel like we've really gone backwards on that aspect concerning TV. I remember a time where I could turn on the TV and be 3 channels further all within the space of 2 seconds. Now my "smart" TV takes 5 seconds just for a first paint, and changing a channel once takes a second. You just can't beat the latency of analog circuits!

Asooka 9y ago
You mean uncompressed data. Yes, analogue is uncompressed, but digital could also be uncompressed. However, everyone wants to stuff more video, more audio over the link, so we compress... Bandwidth goes up, latency also goes up, and things get more complicated...
- blattimwind 9y ago
  Analogue video signals are absolutely compressed (interlacing, PAL, NTSC, SECAM). It's just not as efficient as MPEG-X combined with hyper-aggressive modulation schemes and forward-error correction, channel-capacity wise.
mark-r 9y ago
My new car has a radio with a touch-screen interface. When I turn the car on there's a space of about 10 seconds where the radio is operating but I can't change the station or volume or even turn it off. It's quite annoying when you were rocking out last time you were in the car and now you have passengers.
- wpietri 9y ago
  To me this is symptomatic of a long or broken feedback loop in the development process. E.g., a classic waterfall approach where somebody writes a big spec, a team spends a bunch of time implementing, and then sometime at or after the deadline, a working model is produced. 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).
  - userbinator 9y ago
    a classic waterfall approach where somebody writes a big spec, a team spends a bunch of time implementing, and then sometime at or after the deadline, a working model is produced. ...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.
    - wpietri 9y ago
      I think the choice of process is basically orthogonal. Waterfall and Agile processes done well both have been demonstrated to produce safety-critical software. (See, e.g., Nancy van Schooenderwoert's work in medical devices.) Both can produce dangerous software. (E.g., Toyota's "unintended acceleration" issues.) The question is much more about what practices you put in place to assure quality. 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.
ryandrake 9y ago
The radios from my various cars throughout the years are just as bad. My 1970s era radio turned on instantly and there was zero delay as I tuned through channels with a nice smooth analog dial. My 1990s era radio took about 500ms from power on to audio output. The "dial" had steps in it though and was not continuous, and there was a noticeable (again probably around 500ms) delay between when 'click' tactile feedback and when the station was successfully tuned. My current car takes 15 seconds just to boot (WTF), and then I have to navigate some horrible menu just to get to the radio controls. It's like these guys are actively trying to make things worse.
- userbinator 9y ago
  Even the 1980s car radios with digital controls had no perceptible delay, despite containing microcontrollers with a tiny fraction of the speed and memory of the modern ones. 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...

georgeglue1 9y ago

It sounds like you could build a TV/device that caches key frames for all channels on the client/consumer0side. Or am I totally misreading this?

namibj 9y ago
For sattelite tv you wouls need to handle over a Gigabit mpeg-2. Not easy.
- mickronome 9y ago
  Caching without decoding would still be a nice boost, wouldn't it ? 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.
  - jimktrains2 9y ago
    You'd still need the additional tuner(s) to provide the data to cache.
KSS42 9y ago
There are set top boxes that have many tuners. The STB uses the extra tuners to anticipate a channel change and tune ahead to the next channel. (Fast Channel switch).

BLanen 9y ago

Audio compression doesn't work that way. It doesn't use keyframes.

jimktrains2 9y ago
It has some kind of equivalent from my understanding. MP3 has frames https://en.wikipedia.org/wiki/MP3#File_structure https://en.wikipedia.org/wiki/MP3#File_structure and I'd assume all methods do, otherwise how could you start decompression if you don't have a starting point?
- TD-Linux 9y ago
  The prediction gain of audio codecs is <1, which basically means that if you start at a random packet, once you play enough packets it'll converge to sound the same as if you had started playing from the beginning. It'll sound bad at the beginning though, so you usually crop off the first bit after seeking (80ms for Opus, much longer for other codecs). Another source of delay is just the length of audio packets themselves (have to wait for the beginning of one) and radio limitations.
- mortehu 9y ago
  MP3 frames are all full frames, whereas a key frame is a full frame that is followed by incremental updates.

danmaz74 9y ago

Technical detail: for video, key frames are compressed. And this technique isn't used for audio.

jimktrains2 9y ago
> for video, key frames are compressed But they're compressed in such a way that doesn't require any previous frame. It's compressed like a picture would be.