<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
     xmlns:content="http://purl.org/rss/1.0/modules/content/"
     xmlns:dc="http://purl.org/dc/elements/1.1/"
     xmlns:dcterms="http://purl.org/dc/terms/"
     xmlns:media="http://search.yahoo.com/mrss/"
     xmlns:atom="http://www.w3.org/2005/Atom"
     xmlns:cf="https://www.futureplc.com/rss/content-flags"
>
    <channel>
                    <atom:link href="https://www.tvtechnology.com/feeds/tag/livewire" rel="self" type="application/rss+xml" />
                            <title><![CDATA[ Latest from Tv Technology in Livewire ]]></title>
                <link>https://www.tvtechnology.com/tag/livewire</link>
        <description><![CDATA[ All the latest livewire content from the Tv Technology team ]]></description>
                                    <lastBuildDate>Thu, 11 Oct 2018 15:44:56 +0000</lastBuildDate>
                            <language>en</language>
                                <item>
                                                            <title><![CDATA[ Adding AoIP to Existing Facilities ]]></title>
                                                                                                <dc:content><![CDATA[ <p>At this year’s NAB Show, I was engaged in a discussion about audio over IP with Phil Wagner, recently named president of Apogee, when he mentioned that no one was really discussing how to merge the technology into existing television environments. My own columns have been pointed more toward implementing it into new builds.</p><p><strong>THINGS TO KEEP IN MIND</strong></p><p>There are really just a few key things to keep in mind when tossing AoIP equipment into the technology mix of a current broadcast plant, but with SMPTE ST-2110-based facilities coming online and AoIP beginning to manifest itself in a very physical sense, this seems like a good time to look at them.</p><p>Just as we’ve done since television audio became digital, everything in the plant needs to be referenced to the same master clock. This has traditionally meant providing either black, tri-level, word clock or AES reference (DARS), but network connected devices—surprise—look for their clock on the network, which means we now need to provide them with an IEEE 1588 Precision Time Protocol (PTP) clock, which has been referenced to the house master. In the past this might have been achieved with a master clock from the IT world, but broadcast device manufacturers now provide master sync generators that include PTP alongside standard reference signals. Reference remains critical because the audio going through those network cables is still digital, so nasty tics, pops or complete lack of audio is the result when the reference clock is missing or incorrect.</p><p>Choosing a specific AoIP technology can seem like a daunting task since incompatibilities remain even with the publication of the AES67 standard. Remember that AES67 is not an end-to-end solution but is a defined set of internet protocols that, if followed, will allow audio to pass from one AoIP device to another. The good news is that virtually all AoIP equipment manufacturers ship their newer products with an AES67 compatibility mode of some sort, which ensures that audio will pass when connecting a box with one AoIP technology to a box with a different AoIP technology.</p><p>The bad news is that the audio is all that is guaranteed. Sticking with a given AoIP technology, Dante, LiveWire, Ravenna or WheatNet for instance, provide a more end-to-end solution so that all AoIP equipment on the network is aware of each other and information can be shared between them. It also means having full control of those devices, allowing routing and management. Mixing AoIP technologies doesn’t preclude the possibility of doing any of these things, but the lack of information sharing between technologies can make it very, very difficult.</p><p><strong>OPERATING IN AES67 MODE</strong></p><p>Careful planning is the best course of action before heading down the AoIP road. Since AES67 is the PCM audio transport of ST-2110, any AoIP devices in the broadcast chain will most likely need to operate in AES67 mode, so it is necessary to determine what, if any, features are lost when switching devices to this mode. Since discovery, control and management are not part of AES67, it is also critical to determine how this will be done prior to adding AoIP devices to the plant.</p><figure class="van-image-figure pull-" data-bordeaux-image-check ><div class='image-full-width-wrapper'><div class='image-widthsetter' ><p class="vanilla-image-block" style="padding-top:56.25%;"><img id="WDruEvqfDtrREo3DwzXyNZ" name="" alt="JT-NM roadmap of networked media open interoperability" src="https://cdn.mos.cms.futurecdn.net/WDruEvqfDtrREo3DwzXyNZ-1920-80.jpg" mos="https://cdn.mos.cms.futurecdn.net/WDruEvqfDtrREo3DwzXyNZ.jpg" align="" fullscreen="" width="" height="" attribution="" endorsement="" class="pull-"></p></div></div><figcaption itemprop="caption description" class="pull-"><span class="caption-text">JT-NM roadmap of networked media open interoperability </span></figcaption></figure><p>As previously mentioned, sticking with one technology or manufacturer will solve this problem, but this may not provide all the necessary pieces. There are now some third-party software products that promise to make differing AoIP solutions work together despite their differences, but a demonstration of the software controlling actual hardware seems in order before committing to this.</p><p>A solid solution seems on the very near horizon however, and it is already part of the ST-2110 package of standards. Obviously, ST-2110 will need discovery and registration, connection management and control, so the Advanced Media Workflow Association (AMWA) Network Media Open Specifications (NMOS) IS-04 and IS-05 have been chosen to solve those needs for ST-2110 devices. This means that AoIP devices in television facilities will use AES67 for audio transport, IS-04 to locate each other, and IS-05 to connect. Actual implementation of these specifications will be through additional software, but this is the current solution planned for SMPTE ST-2110.</p><p>A temporary workaround to the lack of discovery, connection and control across all AoIP technologies is to build an AoIP system from a single technology, then isolate this AoIP island from the rest of the plant with the exception of converting signals going in and out of these rooms. This could work for an audio suite (or group of suites) or even live mix rooms where IO to the room is self-contained and does not need to interface with other IO other than for ingest and playout. Outfitting professional broadcast audio consoles (and some semi-pro models) with AoIP alongside SDI, MADI, AES, analog IO as part of the system’s configuration is becoming standard practice. Achieving the same thing in video edit suites and the greater facility will prove a bit more difficult, and will involve more interstitial pieces. But again, advance planning is key, and part of that planning should be looking toward the facility’s future and not just its current state.</p><p>Probably the easiest part of adding AoIP devices to a television facility is connecting existing audio and networked audio devices together. There is more to it than just plugging in Ethernet cables for the AoIP devices themselves, since they need to be set up properly on the network. The type of network and its particular setup will determine how complex this actually is. Yet when it comes to interfacing AoIP devices with traditional audio devices there are plenty of solutions available of all types.</p><p>Attention needs to be paid to the underlying technology and whether it has an AES67 mode, but not every piece will be part of the broadcast chain.</p><p><em>Jay Yeary is a television engineer who specializes in audio. He can be contacted through</em><strong>TV Technology</strong><em>magazine.</em></p> ]]></dc:content>
                                                                                                                                            <link>https://www.tvtechnology.com/opinions/adding-aoip-to-existing-facilities</link>
                                                                            <description>
                            <![CDATA[ Careful planning is the best course of action before heading down the AoIP road. ]]>
                                                                                                            </description>
                                                                                                                                <guid isPermaLink="false">eddeb1UxnELzL9wE9B9o5u</guid>
                                                                                                <enclosure url="https://cdn.mos.cms.futurecdn.net/aKCJMnDH7HgvCJpJZf22en-1920-80.jpg" type="image/jpeg" length="0"></enclosure>
                                                                        <pubDate>Thu, 11 Oct 2018 15:44:56 +0000</pubDate>                                                                                                                                                                                                                                <category><![CDATA[Opinion]]></category>
                                                    <category><![CDATA[Insights]]></category>
                                                                                                                    <dc:creator><![CDATA[ Jay Yeary ]]></dc:creator>                                                                                                        <dc:description><![CDATA[ null ]]></dc:description>
                                                                                                                                <cf:isSponsored>false</cf:isSponsored>
                <cf:hasAffiliateLinks>false</cf:hasAffiliateLinks>
                <cf:isPaid>false</cf:isPaid>
                                                                                                                                <media:content type="image/jpeg" url="https://cdn.mos.cms.futurecdn.net/aKCJMnDH7HgvCJpJZf22en-1920-80.jpg">
                                                            <media:credit><![CDATA[null]]></media:credit>
                                                                                                                                                                                                                                                                                                                                                    </media:content>
                                                    <media:thumbnail url="https://cdn.mos.cms.futurecdn.net/aKCJMnDH7HgvCJpJZf22en-1920-80.jpg" />
                                                                                                                                                                    <content:encoded >
                            <![CDATA[
                            <article>
                                <p>At this year’s NAB Show, I was engaged in a discussion about audio over IP with Phil Wagner, recently named president of Apogee, when he mentioned that no one was really discussing how to merge the technology into existing television environments. My own columns have been pointed more toward implementing it into new builds.</p><p><strong>THINGS TO KEEP IN MIND</strong></p><p>There are really just a few key things to keep in mind when tossing AoIP equipment into the technology mix of a current broadcast plant, but with SMPTE ST-2110-based facilities coming online and AoIP beginning to manifest itself in a very physical sense, this seems like a good time to look at them.</p><p>Just as we’ve done since television audio became digital, everything in the plant needs to be referenced to the same master clock. This has traditionally meant providing either black, tri-level, word clock or AES reference (DARS), but network connected devices—surprise—look for their clock on the network, which means we now need to provide them with an IEEE 1588 Precision Time Protocol (PTP) clock, which has been referenced to the house master. In the past this might have been achieved with a master clock from the IT world, but broadcast device manufacturers now provide master sync generators that include PTP alongside standard reference signals. Reference remains critical because the audio going through those network cables is still digital, so nasty tics, pops or complete lack of audio is the result when the reference clock is missing or incorrect.</p><p>Choosing a specific AoIP technology can seem like a daunting task since incompatibilities remain even with the publication of the AES67 standard. Remember that AES67 is not an end-to-end solution but is a defined set of internet protocols that, if followed, will allow audio to pass from one AoIP device to another. The good news is that virtually all AoIP equipment manufacturers ship their newer products with an AES67 compatibility mode of some sort, which ensures that audio will pass when connecting a box with one AoIP technology to a box with a different AoIP technology.</p><p>The bad news is that the audio is all that is guaranteed. Sticking with a given AoIP technology, Dante, LiveWire, Ravenna or WheatNet for instance, provide a more end-to-end solution so that all AoIP equipment on the network is aware of each other and information can be shared between them. It also means having full control of those devices, allowing routing and management. Mixing AoIP technologies doesn’t preclude the possibility of doing any of these things, but the lack of information sharing between technologies can make it very, very difficult.</p><p><strong>OPERATING IN AES67 MODE</strong></p><p>Careful planning is the best course of action before heading down the AoIP road. Since AES67 is the PCM audio transport of ST-2110, any AoIP devices in the broadcast chain will most likely need to operate in AES67 mode, so it is necessary to determine what, if any, features are lost when switching devices to this mode. Since discovery, control and management are not part of AES67, it is also critical to determine how this will be done prior to adding AoIP devices to the plant.</p><figure class="van-image-figure pull-" data-bordeaux-image-check ><div class='image-full-width-wrapper'><div class='image-widthsetter' ><p class="vanilla-image-block" style="padding-top:56.25%;"><img id="WDruEvqfDtrREo3DwzXyNZ" name="" alt="JT-NM roadmap of networked media open interoperability" src="https://cdn.mos.cms.futurecdn.net/WDruEvqfDtrREo3DwzXyNZ-1920-80.jpg" mos="https://cdn.mos.cms.futurecdn.net/WDruEvqfDtrREo3DwzXyNZ.jpg" align="" fullscreen="" width="" height="" attribution="" endorsement="" class="pull-"></p></div></div><figcaption itemprop="caption description" class="pull-"><span class="caption-text">JT-NM roadmap of networked media open interoperability </span></figcaption></figure><p>As previously mentioned, sticking with one technology or manufacturer will solve this problem, but this may not provide all the necessary pieces. There are now some third-party software products that promise to make differing AoIP solutions work together despite their differences, but a demonstration of the software controlling actual hardware seems in order before committing to this.</p><p>A solid solution seems on the very near horizon however, and it is already part of the ST-2110 package of standards. Obviously, ST-2110 will need discovery and registration, connection management and control, so the Advanced Media Workflow Association (AMWA) Network Media Open Specifications (NMOS) IS-04 and IS-05 have been chosen to solve those needs for ST-2110 devices. This means that AoIP devices in television facilities will use AES67 for audio transport, IS-04 to locate each other, and IS-05 to connect. Actual implementation of these specifications will be through additional software, but this is the current solution planned for SMPTE ST-2110.</p><p>A temporary workaround to the lack of discovery, connection and control across all AoIP technologies is to build an AoIP system from a single technology, then isolate this AoIP island from the rest of the plant with the exception of converting signals going in and out of these rooms. This could work for an audio suite (or group of suites) or even live mix rooms where IO to the room is self-contained and does not need to interface with other IO other than for ingest and playout. Outfitting professional broadcast audio consoles (and some semi-pro models) with AoIP alongside SDI, MADI, AES, analog IO as part of the system’s configuration is becoming standard practice. Achieving the same thing in video edit suites and the greater facility will prove a bit more difficult, and will involve more interstitial pieces. But again, advance planning is key, and part of that planning should be looking toward the facility’s future and not just its current state.</p><p>Probably the easiest part of adding AoIP devices to a television facility is connecting existing audio and networked audio devices together. There is more to it than just plugging in Ethernet cables for the AoIP devices themselves, since they need to be set up properly on the network. The type of network and its particular setup will determine how complex this actually is. Yet when it comes to interfacing AoIP devices with traditional audio devices there are plenty of solutions available of all types.</p><p>Attention needs to be paid to the underlying technology and whether it has an AES67 mode, but not every piece will be part of the broadcast chain.</p><p><em>Jay Yeary is a television engineer who specializes in audio. He can be contacted through</em><strong>TV Technology</strong><em>magazine.</em></p>
                                                            </article>
                            ]]>
                        </content:encoded>
                                                </item>
                                <item>
                                                            <title><![CDATA[ Understanding the Livewire+ AES67 Protocol ]]></title>
                                                                                                <dc:content><![CDATA[ <p>Over the last 15 to 20 years, broadcast audio systems have undergone revolutionary changes—from analog to digital technologies, from manual to computer-assisted workflows, integrating related systems such as telephones and intercom systems, and much more.</p><p>One key enabling technology is Audio over IP (AoIP), which delivers a number of significant benefits, including operational flexibility, scalability and lower costs. However, implementing AoIP systems to take advantage of these benefits depends almost entirely on the existence of and support for interface and interoperability standards to ensure that the many elements that make up professional audio systems are capable of working together. To that end, there are several AoIP protocols designed to achieve this goal by easing implementation and integration, including the increasingly popular Livewire+ AES67.</p><p>Originally known as Livewire, this pioneering technology was created in 2003 by the Telos Alliance as a means of transmitting low-latency, high-reliability audio over switched Ethernet. Livewire+ AES67 adds full compliance with the AES67-2013 interoperability standard for high-performance AoIP transport over IP audio networking products. This allows devices to seamlessly connect directly to Livewire+ networks for connecting audio streams, regardless of device type or manufacturer. Livewire+ AES67 also offers the flexibility to incorporate and comply with future AES and SMPTE standards as they are approved and released, while simultaneously offering backward compatibility with the RAVENNA networking protocol.</p><p>Today, 70,000 connected devices worldwide use the Livewire or Livewire+ AES67 protocols, and 100 companies provide compatible equipment. While these numbers are impressive, adoption continues to grow steadily for a number of key reasons.</p><p><strong>EASE OF INSTALLATION AND USE</strong></p><p>In the coming years, studios’ transition to IP will continue, but the number of available protocols, methods, hardware and audio devices can make the process confusing. Livewire+ AES67 cuts through this noise to accomplish interconnectivity more easily at a lower cost.</p><p>Using Livewire+ AES67, uncompressed digital audio, device control messages, program-associated data and routine network traffic is carried over a single Ethernet cable in real time. This reduces the number of cables to deploy, significantly reducing the time required to wire an entire facility. All sources and devices connect using readily available Ethernet cables, which can carry up to 250 audio channels each, depending on the network link capacity. This link aggregation eliminates expensive multi-pair cable for interconnecting studios, resulting in potentially significant savings in labor costs alone.</p><p>Configuration can also be just as simple. With Livewire+ AES67, every audio source is given a text name and numeric ID, which are transmitted from devices over the network thanks to a built-in device discovery mechanism. All hardware products have built-in web engines that can be accessed via any common browser or by using an Axia program called iProbe. Users simply enter the names of their desired input sources using just a PC and web browser, with a configuration window enabling any necessary parameter changes for the selected sources.</p><p>As a result of these capabilities, installation and configuration, which may have taken weeks in the past, can now be completed in hours thanks to Livewire+ AES67.</p><p><strong>AUDIO QUALITY AND RELIABILITY</strong></p><p>Unlike Internet audio, which suffers from reduced quality as a result of limited and variable bandwidth, Livewire+ AES67 uses Internet protocols but is intended to deliver uncompressed audio over local area networks (LANs). Livewire+ AES67 is the only fully compliant protocol that also features Unicast SIP modes of operation, meaning it is also suitable for VLAN and WAN applications.</p><p>The controlled, high-speed Livewire+ AES67 network provides more than adequate bandwidth for large numbers of channels of high-quality uncompressed audio in real time, eliminating the risk of audio drop-outs from network outages and other issues affecting transmission. Long accepted as a reliable means of transporting virtually any kind of data or signal, IP has become a reliable option for telephone, intercom, teleconferencing and many other applications. According to the Telos Alliance, as of April 2015, more than 5,500 studios around the world had been built using the company’s Axia IP-audio infrastructure employing the Livewire+ AES67 protocol for mission-critical broadcast applications in major metropolitan markets.</p><p><strong>COST SAVINGS</strong></p><p>A key benefit of Livewire+ AES67 is its ability to enable computer data, phone, audio and control to be transmitted on a single network. Naturally, this type of converged networking environment can generate significant cost-efficiencies throughout a broadcast facility.</p><p>Further contributing to the cost-effectiveness of Livewire+ AES67 is that the most widely used and highly respected companies in the radio industry have adopted the technology. This allows broadcasters to select best-of-breed solutions and connect as many audio devices as possible directly to their audio network. In addition to simplicity, this removes the need for extra I/O devices, delivering even lower overall system costs.</p><p>Livewire+ AES67 allows wiring to be installed in hours, as opposed to the weeks that are often required. Livewire+ also generates savings from the way it handles audio from PCs, which nearly all broadcast stations use as their primary means of playing and editing audio. With a traditional network, PC-based audio is transmitted through a router input card or console module, which adds significant cost when bringing multiple audio channels into the system.</p><p>The latest release of Livewire+ AES67 includes a driver that can handle up to 24 bi-directional stereo or mono audio streams directly through a computer’s network card and now features PTP clock synchronization. This allows the computer to be connected directly to the network using an existing Ethernet connection, eliminating the cost of an additional sound card and the port needed to connect it to a console or router. In many cases, this can save broadcasters many thousands of dollars.</p><p>Studios’ transition to IP-based broadcasting has been underway for several years, but has been hindered by the sheer number of protocols, integration methods, legacy hardware and advanced audio devices, which can be confusing at best. The advanced capabilities and other key benefits of Livewire+ AES67, on the other hand, simplifies interconnectivity and upgrades, while offering greater flexibility and cost-effectiveness.</p><p>By implementing Livewire+ AES67 solutions, studios can take advantage of best-of-breed technologies to satisfy a wider range of applications within network environments. Best of all, Livewire+ AES67 is designed to work with future standards as they are released. This ensures that the Livewire+ AES67 will never be obsolete and continue to deliver quality, reliability, flexibility, cost savings and many more benefits well into the future.</p><p><em>John Schur is the president of Telos Alliance TV Solutions Group.</em></p> ]]></dc:content>
                                                                                                                                            <link>https://www.tvtechnology.com/opinions/understanding-the-livewire-aes67-protocol</link>
                                                                            <description>
                            <![CDATA[ Over the last 15 to 20 years, broadcast audio systems have undergone revolutionary changes—from analog to digital technologies, from manual to computer-assisted workflows, integrating related systems such as telephones and intercom systems, and much more. ]]>
                                                                                                            </description>
                                                                                                                                <guid isPermaLink="false">jumJVsjqV112vpGpo4Zj7R</guid>
                                                                                                <enclosure url="https://cdn.mos.cms.futurecdn.net/W3EMHd7sBYySFKvfBfgH9A-1920-80.jpg" type="image/jpeg" length="0"></enclosure>
                                                                        <pubDate>Fri, 12 Jan 2018 09:07:00 +0000</pubDate>                                                                                                                                                                                                                                <category><![CDATA[Opinion]]></category>
                                                    <category><![CDATA[Insights]]></category>
                                                                                                                    <dc:creator><![CDATA[ John Schur ]]></dc:creator>                                                                                                        <dc:description><![CDATA[ null ]]></dc:description>
                                                                                                                                <cf:isSponsored>false</cf:isSponsored>
                <cf:hasAffiliateLinks>false</cf:hasAffiliateLinks>
                <cf:isPaid>false</cf:isPaid>
                                                                                                                                <media:content type="image/jpeg" url="https://cdn.mos.cms.futurecdn.net/W3EMHd7sBYySFKvfBfgH9A-1920-80.jpg">
                                                            <media:credit><![CDATA[null]]></media:credit>
                                                                                                                                                                                                                                                                                                                                                    </media:content>
                                                    <media:thumbnail url="https://cdn.mos.cms.futurecdn.net/W3EMHd7sBYySFKvfBfgH9A-1920-80.jpg" />
                                                                                                                                                                    <content:encoded >
                            <![CDATA[
                            <article>
                                <p>Over the last 15 to 20 years, broadcast audio systems have undergone revolutionary changes—from analog to digital technologies, from manual to computer-assisted workflows, integrating related systems such as telephones and intercom systems, and much more.</p><p>One key enabling technology is Audio over IP (AoIP), which delivers a number of significant benefits, including operational flexibility, scalability and lower costs. However, implementing AoIP systems to take advantage of these benefits depends almost entirely on the existence of and support for interface and interoperability standards to ensure that the many elements that make up professional audio systems are capable of working together. To that end, there are several AoIP protocols designed to achieve this goal by easing implementation and integration, including the increasingly popular Livewire+ AES67.</p><p>Originally known as Livewire, this pioneering technology was created in 2003 by the Telos Alliance as a means of transmitting low-latency, high-reliability audio over switched Ethernet. Livewire+ AES67 adds full compliance with the AES67-2013 interoperability standard for high-performance AoIP transport over IP audio networking products. This allows devices to seamlessly connect directly to Livewire+ networks for connecting audio streams, regardless of device type or manufacturer. Livewire+ AES67 also offers the flexibility to incorporate and comply with future AES and SMPTE standards as they are approved and released, while simultaneously offering backward compatibility with the RAVENNA networking protocol.</p><p>Today, 70,000 connected devices worldwide use the Livewire or Livewire+ AES67 protocols, and 100 companies provide compatible equipment. While these numbers are impressive, adoption continues to grow steadily for a number of key reasons.</p><p><strong>EASE OF INSTALLATION AND USE</strong></p><p>In the coming years, studios’ transition to IP will continue, but the number of available protocols, methods, hardware and audio devices can make the process confusing. Livewire+ AES67 cuts through this noise to accomplish interconnectivity more easily at a lower cost.</p><p>Using Livewire+ AES67, uncompressed digital audio, device control messages, program-associated data and routine network traffic is carried over a single Ethernet cable in real time. This reduces the number of cables to deploy, significantly reducing the time required to wire an entire facility. All sources and devices connect using readily available Ethernet cables, which can carry up to 250 audio channels each, depending on the network link capacity. This link aggregation eliminates expensive multi-pair cable for interconnecting studios, resulting in potentially significant savings in labor costs alone.</p><p>Configuration can also be just as simple. With Livewire+ AES67, every audio source is given a text name and numeric ID, which are transmitted from devices over the network thanks to a built-in device discovery mechanism. All hardware products have built-in web engines that can be accessed via any common browser or by using an Axia program called iProbe. Users simply enter the names of their desired input sources using just a PC and web browser, with a configuration window enabling any necessary parameter changes for the selected sources.</p><p>As a result of these capabilities, installation and configuration, which may have taken weeks in the past, can now be completed in hours thanks to Livewire+ AES67.</p><p><strong>AUDIO QUALITY AND RELIABILITY</strong></p><p>Unlike Internet audio, which suffers from reduced quality as a result of limited and variable bandwidth, Livewire+ AES67 uses Internet protocols but is intended to deliver uncompressed audio over local area networks (LANs). Livewire+ AES67 is the only fully compliant protocol that also features Unicast SIP modes of operation, meaning it is also suitable for VLAN and WAN applications.</p><p>The controlled, high-speed Livewire+ AES67 network provides more than adequate bandwidth for large numbers of channels of high-quality uncompressed audio in real time, eliminating the risk of audio drop-outs from network outages and other issues affecting transmission. Long accepted as a reliable means of transporting virtually any kind of data or signal, IP has become a reliable option for telephone, intercom, teleconferencing and many other applications. According to the Telos Alliance, as of April 2015, more than 5,500 studios around the world had been built using the company’s Axia IP-audio infrastructure employing the Livewire+ AES67 protocol for mission-critical broadcast applications in major metropolitan markets.</p><p><strong>COST SAVINGS</strong></p><p>A key benefit of Livewire+ AES67 is its ability to enable computer data, phone, audio and control to be transmitted on a single network. Naturally, this type of converged networking environment can generate significant cost-efficiencies throughout a broadcast facility.</p><p>Further contributing to the cost-effectiveness of Livewire+ AES67 is that the most widely used and highly respected companies in the radio industry have adopted the technology. This allows broadcasters to select best-of-breed solutions and connect as many audio devices as possible directly to their audio network. In addition to simplicity, this removes the need for extra I/O devices, delivering even lower overall system costs.</p><p>Livewire+ AES67 allows wiring to be installed in hours, as opposed to the weeks that are often required. Livewire+ also generates savings from the way it handles audio from PCs, which nearly all broadcast stations use as their primary means of playing and editing audio. With a traditional network, PC-based audio is transmitted through a router input card or console module, which adds significant cost when bringing multiple audio channels into the system.</p><p>The latest release of Livewire+ AES67 includes a driver that can handle up to 24 bi-directional stereo or mono audio streams directly through a computer’s network card and now features PTP clock synchronization. This allows the computer to be connected directly to the network using an existing Ethernet connection, eliminating the cost of an additional sound card and the port needed to connect it to a console or router. In many cases, this can save broadcasters many thousands of dollars.</p><p>Studios’ transition to IP-based broadcasting has been underway for several years, but has been hindered by the sheer number of protocols, integration methods, legacy hardware and advanced audio devices, which can be confusing at best. The advanced capabilities and other key benefits of Livewire+ AES67, on the other hand, simplifies interconnectivity and upgrades, while offering greater flexibility and cost-effectiveness.</p><p>By implementing Livewire+ AES67 solutions, studios can take advantage of best-of-breed technologies to satisfy a wider range of applications within network environments. Best of all, Livewire+ AES67 is designed to work with future standards as they are released. This ensures that the Livewire+ AES67 will never be obsolete and continue to deliver quality, reliability, flexibility, cost savings and many more benefits well into the future.</p><p><em>John Schur is the president of Telos Alliance TV Solutions Group.</em></p>
                                                            </article>
                            ]]>
                        </content:encoded>
                                                </item>
            </channel>
</rss>