UK DAB Radio

82 readers

1 users here now

Discussion of all things DAB/Digital Radio!

Channel list website: https://www.terrestrialtv.uk/dab

Programme discussion is probably better in [email protected]

Rules

Be nice
Keep on topic
National changes are usually picked up by the bot, but if it hasn't posted feel free to create a new thread.

founded 1 year ago

MODERATORS

[email protected]

FM advantage over DAB: fast tuning -- do DAB devices need to evolve more? (lemmy.sdf.org)

submitted 2 months ago* (last edited 2 months ago) by [email protected] to c/[email protected]

5 comments fedilink hide all child comments

My DAB+ radio also has an FM function. It stores a favorite set of channels for DAB and a separate memory store for FM. When cycling through the DAB presets, there is a ~3 or so second delay for it to tune and decode. With the FM mode there is no delay. Is my particular model just slow with decoding the first sound byte or is this an inherent DAB shortcoming?

I imagine a well designed DAB radio could theoretically tune the next 2 or 3 presets in sequence simultaneously in parallel so you could avoid the channel changing delay. Has anything like that been implemented?

What about a device that pairs FM to DAB? Some radio stations have both an FM and a DAB transmission. So in principle I would want the device to be aware of the dupes. From there, I should be able to flip through the FM stations and once I settle on a station push a single button to switch over to the DAB signal. It could even deliberately play the FM signal for 4 sec. longer and quickly cross-fade in the DAB signal. Any hardware on the market doing this sort of thing?

you are viewing a single comment's thread
view the rest of the comments

[–] slurp 5 points 2 months ago* (last edited 2 months ago) (1 children)

The DAB decode just takes some time - DAB will always have more latency than FM due to the increased processing. Not sure how much that can be shrunk (probably a fair bit but the cost wouldn't be worth it for most people), but the crossfade would not work because the FM would be ahead of the DAB.

The only way to avoid channel changing delay is to constantly be decoding multiple channels, which would likely increase the power consumption and device cost a fair bit.

[–] [email protected] 1 points 2 months ago* (last edited 2 months ago) (1 children)

I figured the power consumption of multiple parallel decodings would increase but it would be negligable if limited to occur during channel browsing. If you settle on a signal for 2 min, it could revert to 1 channel.

A more crude improvement would be trivial: simply continue playing the previous buffer during the 3 second gap, but update the display instantly to show the user that their command was received and acted on. The 3 second gap could also be a fade-out to give an audible signal that the channel change command is in motion. The linux app “Clementine” does some of this. When you click the stop button, it does not stop the music instantly but does a fade out.

DJs sometimes have to switch to something else quickly with no time to beat match. It’s not a good situation but their method of choice seems to be a rapid cross-fade, as opposed to a sharp and sudden discrete switch. That slight smoothness helps. With a small buffer the two channels could even slow one channel and speed up the other to do an automatic beat match and cross-fade a bit more smoothly. I would not be surprised if there were some FOSS libs that already provide this sort of thing.

(edit) I should note as well that there is one station that has a very low level so you have to double the volume to match any other station. A device that fades during transitions could normalize the level differences without the user even knowing the differences are there.

[–] slurp 1 points 2 months ago

The fade-out could work but would add more delay time, but the buffering would almost certainly require additional hardware because radios typically can't process two DAB signals at once and it can't pre-buffer a live broadcast unless it adds an extra delay, which is just shifting the problem to a different cause. Speed ramping could maybe account a bit for this, but then if you change stations multiple times quickly this would fail. Also, speed ramping would probably annoy people, especially for music, unless imperceptibly slow. That would require a decent buffer, meaning you'd have to delay switching the channel and also not change the channel for a bit, otherwise you'd get the pause.

The amount of complexity any potential solution adds is not especially worth it, as much as I recognise that it is annoying. Also, since most people aren't too fussed by the pause, I doubt anyone would bother to produce a radio with the hardware for this (and the software on top).