LONDON�Hopefully, you�ve noticed mention of RadioDNS before in the virtual pages of Digital Radio Update.� �Hybrid radio� is a means by which listeners can enjoy your radio station�s content, whether by over-the-air radio (digital or analog) or via streaming over the public Internet.� The listener�s receiver will switch back and forth between the two media as circumstances warrant, as one important feature.� There is, however, much more to it than that.�
�Hybrid radio is about preserving the core value of our legacy broadcast technology, and modernizing it so it fits in our new IP-centric world.� Hybrid radio has all the new benefits of IP � metrics, personalization, on-demand, visuals, metadata � while preserving the strategic strengths of broadcast � reliability, low-cost, ubiquity,� said Nick Piggott, the Chairman of RadioDNS.� �RadioDNS is the international not-for-profit organization that co-ordinates hybrid radio. Founded in 2010, we create open technical standards, so that broadcasters and manufacturers can be certain that the whole system will interoperate globally, just as radio always has done.�
To my knowledge, there have been no implementations of RadioDNS in North America, though some testing has taken place.� In Europe, and the U.K., RadioDNS has been implemented (as mentionedpreviously in DRU),and we�re fortunate to have the chance to learn more about Global�s implementation of the technology from�Ben Poor, creative technologist atGlobal Radio.�
Doug Irwin:One question I have, from the U.S. standpoint, is about the delay between audio heard by way of the terrestrial transmission, and that of the IP-based transmission. Do you compensate for the different delays, and if so, how?
Ben Poor:�Obviously one of the big differences between traditional broadcast and IP transmission is that with IP you have much larger and more variant delays between the “live” broadcast and what the listener hears. �A delay in itself is not a new thing � DAB receivers are typically behind FM by about 2-3 seconds, depending on codec speeds and the inherent delays within the technology. �One thing about IP delays is that you really cannot reliably predict how delayed it will be. �A delay may likely be different between two devices placed next to each other, and also may vary over time and as the device reconnects and rebuffers a stream.
Both within RadioDNS and also Global there has been a lot of thought put in on how best to account for this. One thing that cannot be easily done is to make an IP stream synchronous to a live stream, so we’re not trying to ‘fix’ the delay. What we can do though is give a device the means to better cope with it.
There are several approaches to this, all of which are useful to different devices, or in different scenarios. �There is no one magic bullet, but a range of things that are optional for both broadcaster and device manufacturer and make the listener experience better.�
The first approach isStream offset. �RadioEPG (I.e. Hybrid Radio SPI, ETSI TS 102 818, now adopted as the international standard for Hybrid and DAB radio service and program information) allows for a station to signal anoffset�against its streams, in milliseconds. This is meant to be a rough estimate of how offset a stream is likely to be when it reaches a device. For example, Global will pick something like 15-20s.
This gives the device a ballpark figure of stream offsets. If I know that my encoding chain will likely delay the audio by a certain amount, I’ll put that as my offset and add a bit for estimated network and device buffering. �It�s optional, so it�s only meant to be a help to devices.
This can be used by devices for their own specific functionality � for example, for a device that switches between broadcast and IP stream, and tries to seamlessly switch using waveform matching, this will give it a rough figure for the time period around which it should do this waveform matching. �It�s not likely to be perfect, although on some in-car devices I’ve usually found it to be that I can’t tell when it switches.
The second approach isIn-Stream Timecode.�Probably similar to other technologies, but certain streaming formats allow in-band metadata to be added. �RadioDNS uses this as a way of passing lookup information into IP streams, but it can also be used to send a timecode. This should be aligned to the time at which the audio frames around it are considered to have ‘happened’, and can be used by devices to sync their own view of time on that audio timeline. �This is useful when the device is also showing Visuals for that feed (I.e. Over RadioVIS), or needs to send time-related information back to the broadcaster (i.e. For RadioTAG), or for whatever other purpose.
This was an idea discussed within the RadioDNS community, and is something that Global do for their streams. Again, it allows us to sync visuals on our mobile apps, and is also very useful downstream for applications that consume our IP feeds and need to be synced up in time.
A third way iswaveform matching,which is a brute-force way of ensuring the audio syncs up between platforms.� Impressive if done well, but disappointing if done badly. It can be improved by better knowing roughly the delay between the live and IP streams, and it�s also something that is useful when switching between DAB and FM streams, or any other platform.
�
Please keep reading Digital Radio Update for the next installment of my conversation with Ben Poor of Global Radio, and look for a more detailed series of articles about RadioDNS in the print version of Radio.��
