49 ms·

I really dislike digital audio broadcasts. They have a higher quality, but the lag associated with changing channels (I change between preset channels a lot) ma

by chomp 9y ago

I really dislike digital audio broadcasts. They have a higher quality, but the lag associated with changing channels (I change between preset channels a lot) makes it really annoying. Also when driving between cities, I can get FM stations for a lot longer distance than the digital ones.

icebraining 9y ago
Is the lag inherent to the protocol, or just a matter of poor receiver implementation?
- jimktrains2 9y ago
  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.
- reaperducer 9y ago
  I can't speak about the DAB protocol, but the HD Radio scheme that is used for digital in the United States seems to be a protocol problem. I say this because I've owned four HD Radios each from a different manufacturer, and each one had the tuning lag problem. 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!
- pjc50 9y ago
  Some buffering is probably inherent. The protocol is at http://www.etsi.org/deliver/etsi_en/300400_300499/300401/01.04.01_40/en_300401v010401o.pdf http://www.etsi.org/deliver/etsi_en/300400_300499/300401/01.... if anyone wants a long read. 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.
  - icebraining 9y ago
    I'm quite ignorant about wireless signals, but do you know why they chose 96ms? That sounds huge for a single frame. I guess an optimization the receivers could do is decode all the presets, then at least switching between those would be instant.
    - mikeash 9y ago
      There's a tradeoff between latency and efficiency. Longer frames can compress better, and you amortize any per-frame header over more stuff. Shorter frames incur more overhead from headers, and may not compress as well. 96ms seems like a reasonable choice for a realtimeish system without tight latency requirements, but I couldn't say why they chose exactly that number.
      - rlpb 9y ago
        > ...but I couldn't say why they chose exactly that number. 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.
- geerlingguy 9y ago
  Also, currently, all decoder chips (at least the 'official' ones you need for an 'HD Radio' designation) are controlled/manufactured/sold by one group, 'Xperi'. The protocol itself is closed/proprietary, and it's not trivial to build any kind of receiver/decoder, like you could with analog FM/AM.
  - zebMcCorkle 9y ago
    HD Radio != DAB
tomjen3 9y ago
I remember the signal as being super crappie for anything not pop music or talk. Out was particularly bad if anybody clapped: it sounded like you are blowing into a piece of aluminum foil. The solution is to kill radio and use the signal to increase internet access, then everybody can hear what they want.
- flyinghamster 9y ago
  Unfortunately, that's just a sliver of spectrum; the entire FM broadcast band is about 20 MHz wide, equivalent to a single 802.11b/g channel. The entire AM (MW) band is little over 1.1 Mhz wide.
  - pdelbarba 9y ago
    Keep in mind that comparing bandwidth between bands that are very far apart isn't super useful. You can easily select down to fractions of 1khz at 1mhz but not at 2.4ghz so 1.1mhz of bandwidth means something different at UHF vs HF/MF.
    - muxator 9y ago
      My memories about radio are a bit faint, so forgive me if I am wrong, but the fact that you ate able to discern narrower channels does not mean that you can transmit more information, doesn't it? As far as I remember, the upper limit to the quantity of information you can send is solely set by the bandwidth, and is not dependent on the carrying frequency.
      - baobrien 9y ago
        That's mostly right, the theoretical limit to the amount of information you can carry over a channel is set by the bandwidth and the channel signal to noise ratio. See the Shannon Limit [1]. I should add, however, the lower frequency you build your radio to operate on, the narrower your channel usually is. Antennas and filters tend to only be well matched over one or a few narrow frequency bands. These bands of good impedance get smaller as you go down in frequency, logarithmically. [1] https://en.wikipedia.org/wiki/Noisy-channel_coding_theorem https://en.wikipedia.org/wiki/Noisy-channel_coding_theorem
interfixus 9y ago
We have regressed on so many audio-related fronts. Our phone conversations may have far better sound today than they used to, but anyone who remembers true analog telephony knows what we have left behind in terms of synchronicity and natural flow of dialogue.
- vhold 9y ago
  On the flip side was getting busy signals because of there not being enough capacity somewhere between you and the person you were calling, and also cross-talk issues, where you could hear other peoples' phone conversations on your line.
  - interfixus 9y ago
    Absolutely. But the natural, two-ways, un-echoed flow of conversation, just as if you were talking to someone in the room - we have lost that, and it's a major loss.
    - vhold 9y ago
      Agreed, heck, I still lament low latency dial-up shell access. Even at 9600 baud it was still more responsive and felt like using a computer in the same room. Chatting with somebody like that, in talk/ytalk/etc, where you could see their every keystroke was a totally different experience because you could even get a vague sense of their thinking process through their pauses and edits.
      - dsr_ 9y ago
        I was using a 9600 baud connection about an hour ago. It sucks rocks. You can see the ascii-menu updating. Everything flickers. (Serial console access to a server, if you really care.) If you run ytalk on a modern machine, it doesn't flicker, but you can still get every keystroke, because that's the protocol.
        BenjiWiebe 9y ago
cup-of-tea 9y ago
The quality is not guaranteed. Many of the DAB stations in the UK are broadcast at such a low bitrate they are noticeably lower quality than good quality FM reception.
- ddingus 9y ago
  The industry trend is clear: Choice over quality. Almost everyone wants sub streams so they can offer more options. Never waste a bit on quality that could be delivering choice.
  - mark-r 9y ago
    In the US everybody wants sub streams so they can sell more commercials. It's all about the money. Thankfully FM is still going strong here.
  - peapicker 9y ago
    Sounds like a recipe to kill radio in favour of higher quality cell data streaming.
    - ddingus 9y ago
      It's never higher quality.
  - pjc50 9y ago
    I believe there was a deliberate choice to keep DAB quality low to avoid people getting clear digital recordings for piracy. Subsequently rendered redundant by Napster, but we are stuck with DAB.
    - ddingus 9y ago
      That was a factor, but the core was more choice. Broadcast used to be about quality. It's quantity now, with "just goos enough" translating to what people will tolerate. Thought experiment for you: Which do you prefer? Low quality, but compelling. Or high quality, not so compelling? That answer is what drives everything. People will take compelling every time. Very few will take quality as a primary factor. More choice = more opportunity to be more compelling = higher AD rates = more revenue per bit.
jhallenworld 9y ago
This bothers me a lot, but strangely, traversing a menu on my Roku to select a station (or youtube video or whatever) does not bother me. If the radio had a menu I could quickly traverse that showed station information and perhaps some kind of preview, then I might be OK with this latency. On the other hand, having to look a menu while driving car is not good.
rhizome 9y ago
My mom just switched from DirectTV to Comcast (...) and one of the "hilarious" parts of the Comcast (X1) experience is their "Changing channel to N..." interstitial when you try to change to another channel.
ajross 9y ago
> the lag associated with changing channels This isn't even an audio thing. With a classic television, you can crank the channel dial and (along with the instant audio output) see a stable frame within 5-20 frames of vsync (so like 300ms or so worst case). My TV at home can't switch an input (e.g. between two HDMI inputs) faster than about 3-4 seconds. No, I don't know why either. It's actually much worse if the device being switched away from is a Chromecast. Don't know why there either.
- IronBacon 9y ago
  I've read a comment here that the HDMI lag on source switch is caused by DRM. I haven't investigated the claim but I consider it plausible... ^__^;
- pfranz 9y ago
  I've heard newer HDMI standards have HDMI Fast Switching. Skimming over the first URL google gave me[1] it sounds like the slowness is because of HDCP (HD Content Protection). Although, it sounds like it will theoretically take it from ~10seconds to maximum of 2 (average of 1) for proper implementations. https://www.synopsys.com/designware-ip/technical-bulletin/hdmi-fast-switching.html https://www.synopsys.com/designware-ip/technical-bulletin/hd...
  - ajross 9y ago
    Looks like "HDMI fast switching" just means "open all the input connections all the time", which is sort of a hack. But yeah, that seems plausible. Of course, in the time it takes for my television to initiate a secure transaction channel with the input hardware on the other side of the cable, my ?!%!? Netflix app has done a arguably more secure transaction with a server on the other side of the continent. Sigh.
    - pfranz 9y ago
      You're in good company > I can send an IP packet to Europe faster than I can send a pixel to the screen. How f’d up is that? John Carmack https://twitter.com/id_aa_carmack/status/193480622533120001?lang=en https://twitter.com/id_aa_carmack/status/193480622533120001?...
Waterluvian 9y ago
XM Radio quality was embarrassingly bad. Quantized robot talk. and their sales were so relentlessly annoying trying to upsell my free trial for my new car.
- silveira 9y ago
  I have XM for a few years. I don't have any problems with audio quality. Reception can go mute under bridges, tunnels, or other large obstacles, but that's that. Otherwise, is the only thing that works on mountains, remote roads, or anywhere really. For the sales, I call them every ~5 months, say I will pay $25+tax for 5 months or something like that, I set the next calendar event.
  - qpalz 9y ago
    My neighborhood is filled with trees so there is a 5 minute part of my commute that XM can't get a signal for more than 5 seconds in a row. It's as if it only takes a single leaf to block the signal.
- joezydeco 9y ago
  XM Radio could be better if they killed about half of the channels. It's just a matter of how much sausage they want to cram into the pipe. When I worked on an XM receiver project, I recall they had about 1.5 mbit of bandwidth to work with. Most stations were 16 or 32Kbit AAC+. The talk stations used 8kbit AMBE, which is pretty much the same as a vocoder. You weren't far off by calling it robot talk.
  - toast0 9y ago
    It doesn't help that they broadcast everything twice, because some of their older receivers have different frequency ranges from before the merger. I think they could do a lot better if they used their modern position to their advantage. Most receivers are in cars, and many cars are coming with always on internet. Hook up to that and a) report on coverage deficiencies, b) fill in from internet streaming when in poor coverage areas, c) get metrics on listener numbers so things that nobody hears can be dropped, d) use streaming to boost bitrate.
makecheck 9y ago
The nice thing about analog is that signals may get weaker but they don’t just go away as easily so you hear continuous music, etc. Digital can be maddening because it alternates between crystal-clear and OFF, which ultimately I think is worse. Some streaming services will also decide to auto-next-song after the slightest glitch which is annoying too.
- cwillu 9y ago
  Anyone who's driven cross-country knows that FM will do that just as bad.
  - khedoros1 9y ago
    Anyone who's driven cross-country knows that FM is nice and clear for a while, then kind of fades out as you reach the edge of the transmitter's range. There's at least a sense of continuity with the drop in signal strength. Digital has a sharp transition between crystal-clear and completely dead. That's the distinction being made above.
    - deleted 9y ago
      [deleted]
- rb2k_ 9y ago
  > Digital can be maddening because it alternates between crystal-clear and OFF, which ultimately I think is worse. Some streaming services will also decide to auto-next-song after the slightest glitch which is annoying too. I wonder if there are audio codecs that work similarly to wavelet based video codecs (DWT instead of DCT) where you could have stepwise degradation.
  - vincnetas 9y ago
    It's a broadcast, you don't know what is the bandwidth of receiving device so you can't adjust accordingly.
zodPod 9y ago
Plus, when they cut out it's actual silence. When FM cuts out it's a little bit of a fade in or static or fade out. Sure both are bad but there's just something about the silence during a digital broadcast interference that is just horrible.
- firethief 9y ago
  Yeah, interruption with noise is much less disruptive than interruption with silence. It's not a drawback of the technology though; it's a design flaw in the receiver not to mask the dropouts with some white noise.
- LeoPanthera 9y ago
  My car's XM (digital satellite in the US) radio generates artificial white noise when the signal drops out. If the signal doesn't come back within a couple of seconds, then you get silence. I'm told GSM phone calls do the same thing, apparently so you can tell the difference between a temporary dropout and a dead line. It's kinda funny.
wvenable 9y ago
Driving long distances I get continuous mobile coverage but radio is non-existent in many places. I can now stream Spotify on a 5 hour drive with no interruptions.
agumonkey 9y ago
random anecdote, I like shitty FM quality. It kills lots of signals but .. I like it. It's like film grain to me.
tjwii 9y ago
> They have a higher quality That's how it is sold indeed, but not entirely true. There is definitely a better signal to noise ratio, but the sample rate is pretty bad which makes the quality lower than normal FM. It's only a 128kbs MP3/AAC stream! It's only because people don't hear noise anymore they think the quality is better. Analog FM is by the way much more robust too as a signal. A shame the government forces people to invest in lower quality qear..
- LeoPanthera 9y ago
  Most DAB stations are MP2, not MP3. MP3 is not supported in DAB. AAC is supported in DAB+, though you need to upgrade your radio again. MP2 is transparent once you get to 256kbit, so the actual codec isn't really the problem, it's the bitrate choice. I don't have any experience of EU DAB, but in the UK, most DAB stations are 128K, which isn't even close to being transparent. The audio quality on FM is considerably better.
  - AnssiH 9y ago
    Almost every station in Norway is DAB+ instead of DAB, most between 64...96kbps. Source http://www.fmlist.org/sendertabelle/dab-ww.php http://www.fmlist.org/sendertabelle/dab-ww.php
TylerE 9y ago
I don't even think it sounds very good, at least the US HD Radio implementation. Most channels have dialed the bitrate way down so they can jam in subchannels of useless stuff like weather and the audio sounds horrible, worse than analog FM.
- FireBeyond 9y ago
  Oh yes. I'm this close to canceling my Sirius subscription because some of the music channels are 32kbps or even 16kbps.
microcolonel 9y ago
I'm not going to take a position on whether DAB is worth it, however: > ...the lag associated with changing channels... It seems like this is mostly the fault of the receiver, to me it doesn't seem like there's any reason that the receiver can't just have several filters (tuned to adjacent or saved channels) and demodulators running, so that you can tune instantly to them. I think the bigger problem with DAB, to my eyes, is codec selection and graceful degradation.
cooper12 9y ago
This is called the Cliff effect btw: https://en.wikipedia.org/wiki/Cliff_effect https://en.wikipedia.org/wiki/Cliff_effect
all_blue_chucks 9y ago
It wouldn't be hard to start a company that builds a radio that buffers every reasonably-strong signal for instant switching...
emmelaich 9y ago
I lament the loss of AM too. I used to get broadcasts from over 500km away. And the sound quality was such that it stayed in the background rather than intrude on conversation.
squarefoot 9y ago
Agreed. To me radio is not for _listening_ to music, which is next to impossible due to constant advertising interruptions, shortened tracks etc (there are online streaming stations for that), so getting very good audio quality instead of good doesn't mean much, while being able to sustain partial loss of signal and switch faster from one station to another is much more important to me.

by chomp 9y ago

icebraining 9y ago

Is the lag inherent to the protocol, or just a matter of poor receiver implementation?

jimktrains2 9y ago
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.
reaperducer 9y ago
I can't speak about the DAB protocol, but the HD Radio scheme that is used for digital in the United States seems to be a protocol problem. I say this because I've owned four HD Radios each from a different manufacturer, and each one had the tuning lag problem. 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!
pjc50 9y ago
Some buffering is probably inherent. The protocol is at http://www.etsi.org/deliver/etsi_en/300400_300499/300401/01.04.01_40/en_300401v010401o.pdf http://www.etsi.org/deliver/etsi_en/300400_300499/300401/01.... if anyone wants a long read. 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.
- icebraining 9y ago
  I'm quite ignorant about wireless signals, but do you know why they chose 96ms? That sounds huge for a single frame. I guess an optimization the receivers could do is decode all the presets, then at least switching between those would be instant.
  - mikeash 9y ago
    There's a tradeoff between latency and efficiency. Longer frames can compress better, and you amortize any per-frame header over more stuff. Shorter frames incur more overhead from headers, and may not compress as well. 96ms seems like a reasonable choice for a realtimeish system without tight latency requirements, but I couldn't say why they chose exactly that number.
    - rlpb 9y ago
      > ...but I couldn't say why they chose exactly that number. 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.
geerlingguy 9y ago
Also, currently, all decoder chips (at least the 'official' ones you need for an 'HD Radio' designation) are controlled/manufactured/sold by one group, 'Xperi'. The protocol itself is closed/proprietary, and it's not trivial to build any kind of receiver/decoder, like you could with analog FM/AM.
- zebMcCorkle 9y ago
  HD Radio != DAB

tomjen3 9y ago

I remember the signal as being super crappie for anything not pop music or talk. Out was particularly bad if anybody clapped: it sounded like you are blowing into a piece of aluminum foil. The solution is to kill radio and use the signal to increase internet access, then everybody can hear what they want.

flyinghamster 9y ago
Unfortunately, that's just a sliver of spectrum; the entire FM broadcast band is about 20 MHz wide, equivalent to a single 802.11b/g channel. The entire AM (MW) band is little over 1.1 Mhz wide.
- pdelbarba 9y ago
  Keep in mind that comparing bandwidth between bands that are very far apart isn't super useful. You can easily select down to fractions of 1khz at 1mhz but not at 2.4ghz so 1.1mhz of bandwidth means something different at UHF vs HF/MF.
  - muxator 9y ago
    My memories about radio are a bit faint, so forgive me if I am wrong, but the fact that you ate able to discern narrower channels does not mean that you can transmit more information, doesn't it? As far as I remember, the upper limit to the quantity of information you can send is solely set by the bandwidth, and is not dependent on the carrying frequency.
    - baobrien 9y ago
      That's mostly right, the theoretical limit to the amount of information you can carry over a channel is set by the bandwidth and the channel signal to noise ratio. See the Shannon Limit [1]. I should add, however, the lower frequency you build your radio to operate on, the narrower your channel usually is. Antennas and filters tend to only be well matched over one or a few narrow frequency bands. These bands of good impedance get smaller as you go down in frequency, logarithmically. [1] https://en.wikipedia.org/wiki/Noisy-channel_coding_theorem https://en.wikipedia.org/wiki/Noisy-channel_coding_theorem

interfixus 9y ago

We have regressed on so many audio-related fronts. Our phone conversations may have far better sound today than they used to, but anyone who remembers true analog telephony knows what we have left behind in terms of synchronicity and natural flow of dialogue.

vhold 9y ago
On the flip side was getting busy signals because of there not being enough capacity somewhere between you and the person you were calling, and also cross-talk issues, where you could hear other peoples' phone conversations on your line.
- interfixus 9y ago
  Absolutely. But the natural, two-ways, un-echoed flow of conversation, just as if you were talking to someone in the room - we have lost that, and it's a major loss.
  - vhold 9y ago
    Agreed, heck, I still lament low latency dial-up shell access. Even at 9600 baud it was still more responsive and felt like using a computer in the same room. Chatting with somebody like that, in talk/ytalk/etc, where you could see their every keystroke was a totally different experience because you could even get a vague sense of their thinking process through their pauses and edits.
    - dsr_ 9y ago
      I was using a 9600 baud connection about an hour ago. It sucks rocks. You can see the ascii-menu updating. Everything flickers. (Serial console access to a server, if you really care.) If you run ytalk on a modern machine, it doesn't flicker, but you can still get every keystroke, because that's the protocol.
      - BenjiWiebe 9y ago

cup-of-tea 9y ago

The quality is not guaranteed. Many of the DAB stations in the UK are broadcast at such a low bitrate they are noticeably lower quality than good quality FM reception.

ddingus 9y ago
The industry trend is clear: Choice over quality. Almost everyone wants sub streams so they can offer more options. Never waste a bit on quality that could be delivering choice.
- mark-r 9y ago
  In the US everybody wants sub streams so they can sell more commercials. It's all about the money. Thankfully FM is still going strong here.
- peapicker 9y ago
  Sounds like a recipe to kill radio in favour of higher quality cell data streaming.
  - ddingus 9y ago
    It's never higher quality.
- pjc50 9y ago
  I believe there was a deliberate choice to keep DAB quality low to avoid people getting clear digital recordings for piracy. Subsequently rendered redundant by Napster, but we are stuck with DAB.
  - ddingus 9y ago
    That was a factor, but the core was more choice. Broadcast used to be about quality. It's quantity now, with "just goos enough" translating to what people will tolerate. Thought experiment for you: Which do you prefer? Low quality, but compelling. Or high quality, not so compelling? That answer is what drives everything. People will take compelling every time. Very few will take quality as a primary factor. More choice = more opportunity to be more compelling = higher AD rates = more revenue per bit.

jhallenworld 9y ago

This bothers me a lot, but strangely, traversing a menu on my Roku to select a station (or youtube video or whatever) does not bother me. If the radio had a menu I could quickly traverse that showed station information and perhaps some kind of preview, then I might be OK with this latency. On the other hand, having to look a menu while driving car is not good.

rhizome 9y ago

My mom just switched from DirectTV to Comcast (...) and one of the "hilarious" parts of the Comcast (X1) experience is their "Changing channel to N..." interstitial when you try to change to another channel.

ajross 9y ago

> the lag associated with changing channels This isn't even an audio thing. With a classic television, you can crank the channel dial and (along with the instant audio output) see a stable frame within 5-20 frames of vsync (so like 300ms or so worst case). My TV at home can't switch an input (e.g. between two HDMI inputs) faster than about 3-4 seconds. No, I don't know why either. It's actually much worse if the device being switched away from is a Chromecast. Don't know why there either.

IronBacon 9y ago
I've read a comment here that the HDMI lag on source switch is caused by DRM. I haven't investigated the claim but I consider it plausible... ^__^;
pfranz 9y ago
I've heard newer HDMI standards have HDMI Fast Switching. Skimming over the first URL google gave me[1] it sounds like the slowness is because of HDCP (HD Content Protection). Although, it sounds like it will theoretically take it from ~10seconds to maximum of 2 (average of 1) for proper implementations. https://www.synopsys.com/designware-ip/technical-bulletin/hdmi-fast-switching.html https://www.synopsys.com/designware-ip/technical-bulletin/hd...
- ajross 9y ago
  Looks like "HDMI fast switching" just means "open all the input connections all the time", which is sort of a hack. But yeah, that seems plausible. Of course, in the time it takes for my television to initiate a secure transaction channel with the input hardware on the other side of the cable, my ?!%!? Netflix app has done a arguably more secure transaction with a server on the other side of the continent. Sigh.
  - pfranz 9y ago
    You're in good company > I can send an IP packet to Europe faster than I can send a pixel to the screen. How f’d up is that? John Carmack https://twitter.com/id_aa_carmack/status/193480622533120001?lang=en https://twitter.com/id_aa_carmack/status/193480622533120001?...

Waterluvian 9y ago

XM Radio quality was embarrassingly bad. Quantized robot talk. and their sales were so relentlessly annoying trying to upsell my free trial for my new car.

silveira 9y ago
I have XM for a few years. I don't have any problems with audio quality. Reception can go mute under bridges, tunnels, or other large obstacles, but that's that. Otherwise, is the only thing that works on mountains, remote roads, or anywhere really. For the sales, I call them every ~5 months, say I will pay $25+tax for 5 months or something like that, I set the next calendar event.
- qpalz 9y ago
  My neighborhood is filled with trees so there is a 5 minute part of my commute that XM can't get a signal for more than 5 seconds in a row. It's as if it only takes a single leaf to block the signal.
joezydeco 9y ago
XM Radio could be better if they killed about half of the channels. It's just a matter of how much sausage they want to cram into the pipe. When I worked on an XM receiver project, I recall they had about 1.5 mbit of bandwidth to work with. Most stations were 16 or 32Kbit AAC+. The talk stations used 8kbit AMBE, which is pretty much the same as a vocoder. You weren't far off by calling it robot talk.
- toast0 9y ago
  It doesn't help that they broadcast everything twice, because some of their older receivers have different frequency ranges from before the merger. I think they could do a lot better if they used their modern position to their advantage. Most receivers are in cars, and many cars are coming with always on internet. Hook up to that and a) report on coverage deficiencies, b) fill in from internet streaming when in poor coverage areas, c) get metrics on listener numbers so things that nobody hears can be dropped, d) use streaming to boost bitrate.

makecheck 9y ago

The nice thing about analog is that signals may get weaker but they don’t just go away as easily so you hear continuous music, etc. Digital can be maddening because it alternates between crystal-clear and OFF, which ultimately I think is worse. Some streaming services will also decide to auto-next-song after the slightest glitch which is annoying too.

cwillu 9y ago
Anyone who's driven cross-country knows that FM will do that just as bad.
- khedoros1 9y ago
  Anyone who's driven cross-country knows that FM is nice and clear for a while, then kind of fades out as you reach the edge of the transmitter's range. There's at least a sense of continuity with the drop in signal strength. Digital has a sharp transition between crystal-clear and completely dead. That's the distinction being made above.
  - deleted 9y ago
    [deleted]
rb2k_ 9y ago
> Digital can be maddening because it alternates between crystal-clear and OFF, which ultimately I think is worse. Some streaming services will also decide to auto-next-song after the slightest glitch which is annoying too. I wonder if there are audio codecs that work similarly to wavelet based video codecs (DWT instead of DCT) where you could have stepwise degradation.
- vincnetas 9y ago
  It's a broadcast, you don't know what is the bandwidth of receiving device so you can't adjust accordingly.

zodPod 9y ago

Plus, when they cut out it's actual silence. When FM cuts out it's a little bit of a fade in or static or fade out. Sure both are bad but there's just something about the silence during a digital broadcast interference that is just horrible.

firethief 9y ago
Yeah, interruption with noise is much less disruptive than interruption with silence. It's not a drawback of the technology though; it's a design flaw in the receiver not to mask the dropouts with some white noise.
LeoPanthera 9y ago
My car's XM (digital satellite in the US) radio generates artificial white noise when the signal drops out. If the signal doesn't come back within a couple of seconds, then you get silence. I'm told GSM phone calls do the same thing, apparently so you can tell the difference between a temporary dropout and a dead line. It's kinda funny.

wvenable 9y ago

Driving long distances I get continuous mobile coverage but radio is non-existent in many places. I can now stream Spotify on a 5 hour drive with no interruptions.

agumonkey 9y ago

random anecdote, I like shitty FM quality. It kills lots of signals but .. I like it. It's like film grain to me.

tjwii 9y ago

> They have a higher quality That's how it is sold indeed, but not entirely true. There is definitely a better signal to noise ratio, but the sample rate is pretty bad which makes the quality lower than normal FM. It's only a 128kbs MP3/AAC stream! It's only because people don't hear noise anymore they think the quality is better. Analog FM is by the way much more robust too as a signal. A shame the government forces people to invest in lower quality qear..

LeoPanthera 9y ago
Most DAB stations are MP2, not MP3. MP3 is not supported in DAB. AAC is supported in DAB+, though you need to upgrade your radio again. MP2 is transparent once you get to 256kbit, so the actual codec isn't really the problem, it's the bitrate choice. I don't have any experience of EU DAB, but in the UK, most DAB stations are 128K, which isn't even close to being transparent. The audio quality on FM is considerably better.
- AnssiH 9y ago
  Almost every station in Norway is DAB+ instead of DAB, most between 64...96kbps. Source http://www.fmlist.org/sendertabelle/dab-ww.php http://www.fmlist.org/sendertabelle/dab-ww.php

TylerE 9y ago

I don't even think it sounds very good, at least the US HD Radio implementation. Most channels have dialed the bitrate way down so they can jam in subchannels of useless stuff like weather and the audio sounds horrible, worse than analog FM.

FireBeyond 9y ago
Oh yes. I'm this close to canceling my Sirius subscription because some of the music channels are 32kbps or even 16kbps.

microcolonel 9y ago

I'm not going to take a position on whether DAB is worth it, however: > ...the lag associated with changing channels... It seems like this is mostly the fault of the receiver, to me it doesn't seem like there's any reason that the receiver can't just have several filters (tuned to adjacent or saved channels) and demodulators running, so that you can tune instantly to them. I think the bigger problem with DAB, to my eyes, is codec selection and graceful degradation.

cooper12 9y ago

This is called the Cliff effect btw: https://en.wikipedia.org/wiki/Cliff_effect https://en.wikipedia.org/wiki/Cliff_effect

all_blue_chucks 9y ago

It wouldn't be hard to start a company that builds a radio that buffers every reasonably-strong signal for instant switching...

emmelaich 9y ago

I lament the loss of AM too. I used to get broadcasts from over 500km away. And the sound quality was such that it stayed in the background rather than intrude on conversation.

squarefoot 9y ago

Agreed. To me radio is not for _listening_ to music, which is next to impossible due to constant advertising interruptions, shortened tracks etc (there are online streaming stations for that), so getting very good audio quality instead of good doesn't mean much, while being able to sustain partial loss of signal and switch faster from one station to another is much more important to me.