TCP, the better option for audio STLs

Transcription

1 Johan van der Stoel TCP, the better option for audio STLs Streamit helps lowering the cost of high quality audio connections

2 BY STREAMIT BV Copyright holder is licensing this under the Creative Commons License, Attribution 3.0. Special thanks to all my collegues at Streamit who gave valuable input to this e-book. Also to Johan van Doornen and other people from Ziggo who helped us in specifying and testing our solution. Read more Disclosures: Some of the people quoted or mentioned in this e-book are my friends and I have business relationships with several of the companies mentioned or profiled. Please feel free to post this on your blog or it to whomever you believe would benefit from reading it. Thank you. TCP, the better option for audio STLs Johan van der Stoel 2

3 TABLE OF CONTENTS Dear Streamit employee Streamit The Ziggo challenge Customer testing first samples STL product Lessons learned from the broadcast market Ultra low delay STL technology issues Practical audio distribution solutions Streamit Products in more detail Where is Streamit now in the market? About the author

4 1 DEAR STREAMIT EMPLOYEE This is the we received at September, 11th 2008 from our first audio STL customer Ziggo, one of the two biggest cable network operators in the Netherlands. An which was the start of developing a new market segment within Streamit. Where can we find you? In 2008 we did not have a booth at the IBC exhibition, but announced on our website we would be there after making an appointment. In 2008 we didn t have any idea about our proposition for the broadcast market. We started learning in 2009 and finally completed our proposition in December, In this e-book I will describe what we learned during this period. I hope that by reading this book your questions about Studio Transmitter Link solutions will be answered. If you have any questions left, do not hesitate to send me an or contact me in another way. Johan van der Stoel TCP, the better option for audio STLs Johan van der Stoel 4

5 2 STREAMIT In 2008 we didn t know much about the broadcast market. We had learned a lot about broadcasting over IP in the churches market where we had developed a solution to connect the church to people who are not able to attend church service anymore. The Lukas internet radio device and the SAS100 Linux-based audio encoder were our most important products in this market. The other market we were active at that time was the in-store audio market. So connecting many shops to one central server using our SIR80 and SIR120 IP-audio receivers. These markets have in common that a reliable IP-audio connection is a must. How to realize a reliable IP-audio connection? In both the churches and the in-store markets, we learned that creating a reliable connection is not so easy. We learned that creating a reliable connection is not so easy We faced the following challenges: Dialup lines which do not have stable modem connections. The most important reason for this is the generally bad wiring in houses. We found the solution by limiting the modem speed to 33.6 kbps instead of max 56 kbps to prevent modem retraining, which is a major cause of hiccups in the audio stream. Customers don t understand IP. For this reason we took the following decisions: As few settings in the devices as possible. Device configuration through a web portal not in the device, but on the internet. TCP, the better option for audio STLs Johan van der Stoel 5

6 2 STREAMIT Device configuration through a PC application for customers with specific requirements which cannot be handled by a web portal, like fixed ip address, proxy server settings. The public internet is not always stable. But... it is almost always there. We addressed these issues by: Implementing a reliable reconnecting algoritm in the receiver device. Implementing intelligent buffer management in the receiver device. Implementing an SD card backup facility in the receiver device. And what if internet is not there? For the in-store audio market we developed a fall-back mechanism to the SD-card, so that in case of serious problems in the internet, there is always music in the shop. And what if you want to know what the status of the radio device is? We have implemented Device Monitoring in our web portal and devices. And what if you want to do something special with your radio device? We have implemented task scheduling in our web portal and devices which enable you to remotely change audio channel, update the SD card with new content and many more advanced features. TCP, the better option for audio STLs Johan van der Stoel 6

7 3 THE ZIGGO CHALLENGE So Ziggo started evaluating our devices and they discovered they operate very stably. Streamit, you can use your technology in the Broadcast market as well! What we need for our local broadcasters is a stable IP audio point to point streaming solution which also can make use of the public internet. Beside a stable streaming solution, we need to have: RDS support XLR audio connectors, both on the receiver and transmitter side No more than a few seconds delay in audio streaming Streamit, you can use your technology in the Broadcast market as well! These were the major requirements for the development of our SAS250 (the transmitter) and SIR150 (the receiver). A big challenge for the SAS250 was the choice of the encoder. Which encoder to choose? We found that we could use 3 compression algorithms: MP3, (e)aac+ and Ogg Vorbis. After investigating which (hardware) implementions are available, doing some subjective listening tests and some internet research we came to the following findings: For comparable bitrates Ogg Vorbis sounds better than MP3. This can also be reformulated as follows: The same (audible) quality audio in Ogg Vorbis requires less storage space (for files) and bandwidth (for streams) than MP3. TCP, the better option for audio STLs Johan van der Stoel 7

8 3 THE ZIGGO CHALLENGE eaac+ (HE-AAC v2) sounds better than Ogg Vorbis in stereo for bitrates 48kbps and higher. AAC+ (HE-AAC v1) sounds comparable to Ogg Vorbis in mono at ~40kbps. Ogg Vorbis sounds better than MP3 and AAC+ (HE-AACv1) in mono at low bitrates (8-24 kbps). The only available hardware-based MP3 encoder offers poor audio quality. Also low-bitrate is not supported. Hardware-based encoders for (e)aac+ are not available. Software licenses are very expensive. For Ogg Vorbis there is a very powerful solution available. Used audio codecs Ogg Vorbis After half a year development time, in December 2009 we supplied the first samples to Ziggo, and a few international customers. TCP, the better option for audio STLs Johan van der Stoel 8

9 4 CUSTOMER TESTING FIRST SAMPLES As the broadcast market was still very new for us, we got lots of responses from our customers on our first samples: The frequency response is not good. The web configuration is not intuitive. The audio levels are not good. What are the exact specifications for the audio response? How much distortion does the audio signal have? How much channel separation is there between the left and right channel? I want to have Telnet access to the devices! Can I also connect more SIR150 s to one SAS250? Pfffffff, how to get satisfied customers? These guys approach it so technically! We never got these kind of questions in our other markets. Why don t they admire our great features? Fantastic audio quality Reliable audio streaming Built-in XLR connectors Reliable external power supply with screw connector Rack mount device Address all the issues one by one and come up with a solution! After many internal discussions we concluded: if we want to become as successful in the broadcast market as in our other markets, we should address all the issues one by one and come up with a solution! TCP, the better option for audio STLs Johan van der Stoel 9

10 5 STL PRODUCT To solve all the issues, (which fortunately could almost all be done in software) we implemented the following improvements. March 2010 Telnet support added Monitoring in ChannelService added Quick start manual added ChannelService web configuration improved August 2010 Improved Ogg Vorbis encoder; this solved the frequency response and related issues. This new encoder also supports higher bitrates. November 2010 Much improved reliability of SAS250 streaming at high bitrates. December 2010 The SAS250 is now able to stream to multiple SIR150 s (also called: point to multipoint streaming) Not all customers require RDS for their STL. So we have decided to introduce the SAS220 and upgrade the SIR120PRO software so that these lower cost products also can be used as audio STL. What is... Device portal about? A question we got from many customers. Broadcasters are used to spending many hours in configuring their devices using an RS232 interface or a webinterface on devices. This indeed is a good method if you do not have a internet connection available (however, we still see room for improvement...), but it is much easier when you can do this using our device configuration and monitoring portal: Streamit Device Portal. Streamit Device Portal TCP, the better option for audio STLs Johan van der Stoel 10

11 6 LESSONS LEARNED FROM THE BROADCAST MARKET One of the first lessons we learned from the Broadcast market is that using the Internet as carrier for broadcast is a very new idea. We have learned that most broadcast people do not have much knowledge about internet technology and IP networking in general. This often leads to frustration, wrong technology decisions but sometimes also over-investments in equipment or networks to prevent any undesired events. This chapter tries to go over the pitfalls we have experienced in our recent broadcast history. We do not have the intention to be complete or claim to have complete knowledge, but I would like to challenge the reader for any comments... To be used for the next version of this book ;-) Public internet vs dedicated links Many broadcasters use (very) expensive dedicated IP lines for the transport of their IP-audio stream. It is our experience (in the Netherlands) that for kbps streams most standard ADSL lines are good enough. The reasons for this are straightforward: IP audio streaming only uses a small part of the available bandwidth: usually kbps is available; only a small part is used. Buffering makes small line drops go unnoticed. We always suggest customers with limited budgets to start with a lowcost ADSL line from a reliable provider. With a reliable provider we mean a provider that has a phone number and is able to support you during the hours you operate your radio station. In case you experience problems, you can always upgrade to a more expensive line. Of course, when you have enough money, do not save on this: a dedicated glass fibre IP link with a Service Level Agreement of 24 hours/7 days per week/15 minutes response time is ideal, of course. Internet as carrier for broadcast is a very new idea Further, it is a good idea to use dedicated (standard ADSL) lines for broadcasting. This ensures that PC users won t block the line in case they are uploading or downloading large files etc. TCP, the better option for audio STLs Johan van der Stoel 11

12 6 LESSONS LEARNED FROM THE BROADCAST MARKET Bandwidth In case you are limited on budget (who isn t nowadays?), you have to take into consideration the amount of bandwidth you need. Of course, the more bandwidth you get delivered on your DSL line, the better it is. Please be careful: on the encoder side you need upstream bandwidth. Usually this bandwidth is much lower than downstream. In case your studio is far away for the telephone exchange, you better apply for a SDSL line. More expensive, but in some cases you have no choice as a reliable upstream is very important. UDP vs TCP UDP TCP How much bandwidth is required? Of course, this depends on your requirements. You have STL s working with a 16 kbit/s stream if you want to connect to a shortwave transmitter. On the other hand, if you want very low delay audio in high quality, even 1 Mbit/s can be too low. UDP vs TCP transport protocol Now we are going into more technical stuff. You may have seen these terms: UDP (User Datagram Protocol) and TCP (Transmission Control Protocol). Both protocols are used for transmitting data from one point to another point. I have summarized the main differences in the table on the right. Guaranteed data delivery No Yes Error correction No Yes Transmission delay Lower Higher What does this mean for audio transmission? This means that in case the internet connection is not very stable with UDP you will loose data. The result of this is very predictable: you will hear disturbances in the audio signal if you do not take any other precautions. If you choose TCP, which has guaranteed delivery of packets, you will not hear any disturbances in the audio signal. At only one penalty: a delay of a few seconds in the audio signal caused by the buffering in the receiver. Unicast vs Multicast vs Broadcast These terms also are often used by broadcast people. Broadcast is familiar, but impossible over the internet. Multicast seems the ideal alternative, but is it really? What do these terms mean in IP networking? TCP, the better option for audio STLs Johan van der Stoel 12

13 6 LESSONS LEARNED FROM THE BROADCAST MARKET Unicast is a type of transmission in which data is sent from one sender to one receiver. Unicast can use both TCP and UDP as communication protocol. Multicast is used to send data from (theoretically more than) one sender to multiple receivers. Only UDP can be used as communication protocol. Also, Multicast is not supported by the public Internet. This means dedicated VPN s 1 need to be configured in order to use this method. This typically is done between two routers, but also can be done between a server and a router or between two servers. The data is transferred using encryption. The multicast protocol mainly is used in large scale IPTV networks, but sometimes also within large company networks. As the setup is rather complicated we do not suggest it to our IP-audio customers as quite often it appears it only generates more problems than it solves. Broadcast is used to send data from one sender to the entire local network. It cannot be used on the public internet, as this data is always dropped at the router. So practically, in most IP-audio STL situations unicast will be used as transmission type. Network delay >75ms In old analogue days, the delay between studio and radio receiver was very short: a few to 100 milliseconds maximum. Due to the digitalisation of many intermediate networks, a lot of delay has been introduced. Also modern public audio distribution networks, like DAB, have introduced a lot of transmission delay. And as most of you know, delay is something we want to prevent as much as possible in broadcast networks. 1 A VPN (Virtual Private Network) is a secure way of connecting to a private LAN (Local Area Network) at a remote location. TCP, the better option for audio STLs Johan van der Stoel 13

14 6 LESSONS LEARNED FROM THE BROADCAST MARKET Above 150ms conversation becomes un-natural; it is difficult for speakers to talk with each other. This is the round trip time, including coding delays and two transits across the network, so the average network latency should be less than (150/2) = 75ms. Above about 40ms musicians have difficulty in performing when hearing their own sound via headphones or loudspeakers. The exact figure is different for different instruments. For speech it is about 50ms. Again, this is the total round trip time, so network latency needs to be below 20ms. So when talking about STL applications, where is network delay critical? We discovered only two situations: Low delay is required all over the world in live radio broadcasting where a reporter/ presenter is broadcasting from a remote location using a radio car or portable analogue radio link. This differs from television where the encoding and uplink delay is such that spontaneous dialogue is near-impossible, so questions and answers usually are scripted. Radio is different, often requiring the distant reporter to respond exactly as if he is faceto-face with the studio presenter. Sometimes a studio signal needs to be broadcasted to several FM transmitters to cover a larger area than one FM transmitter is able to cover. In this application it is important that the signal arrives at the same time at each FM transmitter. My conclusion is that in most other situations a delay of a few seconds should be acceptable. From now on, I will talk about Ultra low delay STL when I talk about the first two situations and STL in case of the other situations. TCP, the better option for audio STLs Johan van der Stoel 14

15 7 ULTRA LOW DELAY STL TECHNOLOGY ISSUES Ultra low delay STL using IP audio technology is not easy: UDP protocol is required to have lowest possible delay All kinds of special audio compression and IP protocols are required to handle error correction and guaranteed data delivery. Generally speaking, this requires a lot more bandwidth compared to standard STL. Sometimes you want to be able to switch some mechanisms on and off in order to optimize your audio connection. I am not the expert in this technology. After investigating this subject, I found some very informative articles about this complicated subject by an expert technology company in this area: APT (recently acquired by CSR). The APT-X technology is used by several manufacturers who have developed equipment for these applications. Interesting links: Read more about the APT-X technology on the CSR website: technology/aptx For more information check out the APT website: TCP, the better option for audio STLs Johan van der Stoel 15

16 8 PRACTICAL AUDIO DISTRIBUTION SOLUTIONS Point to point STL In many cases, audio needs to be transported from one single location to one other location. In this case you just need an IP-audio encoder device at the transmitting side and an IP-audio decoder device on the receiving side. Point-to-point streaming: A stream is sent from one transmitter to one receiver To achieve a reliable connection, we recommend to use TCP as communication protocol. Optionally, we advise to select devices which support monitoring. Either through SNMP or another protocol. This gives you the advantage of monitoring what is happening with your devices and being alerted in case of serious problems. In some cases RDS is also required. There are devices on the market which support the transport of this kind of data. transmitter receiver There are several ways to transport audio... Point to multipoint STL Point-to-multi-point streaming: A stream is sent from one transmitter to several receivers Sometimes the studio signal needs to be transmitted to several locations. For this purpose you can build a multicast setup, but usually it is much easier (as well as cheaper and more reliable) to setup multiple unicast connections from the same encoder, especially when you have enough bandwidth available. The audio quality will be much better! Further the attention points mentioned in the previous paragraph apply: for a reliable connection, we recommend to use TCP as communication protocol and the use of devices which support monitoring. Either through SNMP or another protocol. transmitter receivers TCP, the better option for audio STLs Johan van der Stoel 16

17 8 PRACTICAL AUDIO DISTRIBUTION SOLUTIONS Audio broadcast on the internet Usually a radio station also wants to broadcast to the internet. Technically this broadcast is not possible, as the Internet does not support this feature. For this application audio streaming servers have been developed. The most popular are Shoutcast and Icecast. Shoutcast supports the MP3 and AAC+ protocols, Icecast supports MP3 and Ogg Vorbis. The Microsoft Windows Media Server is becoming less popular. Streaming to Icecast or Shoutcast: The transmitter streams to an Icecast/Shoutcast server and this server distributes the stream to the receivers As for this application usually a lower bitrate is used compared to the connections to broadcast locations, mostly a separate IP audio encoder is required. In some cases the same bit rate can be used, this of course saves in hardware equipment cost as a point to multipoint STL setup can be used in this case. Handling dropouts transmitter Icecast server receivers A difficult problem with internet streaming is the handling of dropouts. Dropouts usually are caused by routers who drop some data because they are too busy or experience buffer overflows - caused by too much data which needs to be transmitted. The result of a dropout is that not all data which is transmitted by the encoder is received by the decoder, which can cause audio hiccups. In case TCP is used, you will not notice these events, as the missed packets are resent by the transmitter. Sometimes dropouts take much longer. For whatever reason. So in these cases there is no connection between encoder and decoder. What to do in these cases? Some decoder devices have an SD card which can be used to play music from there in case there is no connection with the encoder. TCP, the better option for audio STLs Johan van der Stoel 17

18 9 STREAMIT PRODUCTS IN MORE DETAIL In the previous pages I have explained you a lot about STL technology and questions you will encounter when you are searching a solution for your situation. In the next few pages I will summarize briefly the STL solutions Streamit can offer you. Streamit Device Portal I will not start explaining our hardware devices, but start with our Configuration and Management tool: the Streamit Device Portal. The reason for this that we think that once you start using IP devices, the ease of configuring and monitoring of the STL devices becomes very important to you. Our Device Portal has been designed with the following features: Easy device configuration Remote device management Remote device scheduling; this enables you for example - to switch between encoders on preprogrammed times. Device monitoring. If configured, the decoder devices periodically send status information to the portal. Please note that our devices also can be used without the use of the Streamit Device Portal! TCP, the better option for audio STLs Johan van der Stoel 18

19 9 STREAMIT PRODUCTS IN MORE DETAIL SAS220 audio encoders These are our Ogg Vorbis-based audio encoders. They offer the following features: High quality audio encoding Streaming to Icecast and Shoutcast Bitrates between 16 and 160 kbps XLR input connectors Telnet support Rack mount SAS220 front: SAS220 back: TCP, the better option for audio STLs Johan van der Stoel 19

20 9 STREAMIT PRODUCTS IN MORE DETAIL Lisa LCD - Ultimate audio decoders These are our high performance Ogg Vorbis audio decoders. They offer the following features: High quality audio decoding Support also for MP3, AAC+ streams RCA output connectors Telnet support Rack mount Device monitoring through Streamit Device Portal Task scheduling through Streamit Device Portal Automatic fallback to SD card in case of network dropouts Lisa LCD - Ultimate front: Lisa LCD - Ultimate back: TCP, the better option for audio STLs Johan van der Stoel 20

21 10 WHERE IS STREAMIT NOW IN THE MARKET? We started this e-book with our launching customer Ziggo. They have several customers using our STL solution today and this number is still growing. More and more customers are discovering the advantages of using Streamit audio STL solutions. Please visit the Streamit website for finding the neareast distributor or contact us directly in case you want to have more information. Visit the Streamit website for more information about audio STL TCP, the better option for audio STLs Johan van der Stoel 21

22 11 ABOUT THE AUTHOR Johan van der Stoel is CEO and founder of Streamit BV. He can be contacted in the following ways: Skype: jvdstoel Phone: Mobile: Fax: By mail: Streamit BV, Langendijk 7, 5652 AX Eindhoven, The Netherlands IP Media Devices Streamit is a Dutch company specialized in the development and marketing of equipment and platforms for video and audio streaming over the internet. Streamit is known for its innovative in-store audio and STL solutions for music providers, retail chains, churches and broadcasters worldwide. We develop our products for niche markets where quality and specific requirements cannot be met by standard consumer solutions. Address: Web: Streamit BV, Langendijk 7, 5652 AX Eindhoven, The Netherlands info@streamit.eu Phone: TCP, the better option for audio STLs Johan van der Stoel 22