Barix Wiki - User contributions [en]

How do i read an I/O register using SNMP ?

2010-12-02T20:06:40Z

Jrietschel:

I/O registers in the Barionet (1000 instances) either are tied to hardware or just hold values, as an interface to a BCL program in the Barionet.
Registers can be polled and also controlled using standard SNMP get/set requests. For set operations, the community "private" needs to be used (default). These same registers can also be accessed using Modbus/TCP or ASCII control protocols (and even via cgi/web server).

You can easily control the relays, for example, by using SNMP set requests on registers 1 and 2.

The detailed register map is documented in the Barionet manual.

How do the registers map to Object ID's ?

This is defined in the Barionet MIB, which is included in the device (you can access it with the URL /barionet.mib on the device), and on the Barix website.

Here is, for example, the OID for register 201 (digital input 1): 1.3.6.1.4.1.17491.1.1.2.1.2.201

In some systems, you may be able to use a name like this:

SNMPv2-SMI::enterprises.17491.1.1.2.1.2.X - X being the register number, for example. 1..4 for the four relays on the Barionet 50

Specifically, for the relays and digital outputs, the following values can be used:
* 0 (reset the relay), 1 (set the relay),
* 2..998 .. pulse the relay for the value times 100ms (5 is 500ms, 50 would be 5 seconds)
* 999 to toggle the relay.

Example to activate relay 3 using snmpset on OSX:

snmpset -v 1 -c private 192.168.1.121 SNMPv2-SMI::enterprises.17491.1.1.2.1.2.3 u 1

Back to [[FAQ]]

Redundancy

2010-11-19T06:00:30Z

Jrietschel: New page: == Redundancy == This wiki pages contains information about how Barix products can be used with redundant networks, in failsafe applications and the like. Some of the suggested solutions ...

== Redundancy ==

This wiki pages contains information about how Barix products can be used with redundant networks, in failsafe applications and the like. Some of the suggested solutions are not available "from stock" but may incur a development cost, or mean an additional software license

== Network redundancy ==

== Dual device use ==

FAQ

2010-11-19T05:57:17Z

Jrietschel: /* General questions - IP, Addressing, Multicast etc */

== General questions - IP, Addressing, Multicast etc ==

* '''[[Are there any known security vulnerabilities with Barix devices]]'''

* '''[[So, I have purchased an Instreamer and an Exstreamer. And now what?]]'''

* '''[[How do the devices get their IP address ?]]'''

* '''[[What if my routers don't have a fix IP address from the ISP (Internet service provider) ?]]'''

* ''' How do i connect a Barix device to HSPDA, UMTS, CDMA, EVDO, wireless networks ? Please see [[Connecting to 3G Networks]]'''

* '''Ho do I do a web update of a device ? Please see [[FW Update]]'''

* '''[[How do I set the device back to factory defaults ?]]'''

* '''How do I perform a "Serial Rescue" of the device if it becomes unreachable ? Please see [[FW Update]]'''

* '''[[How do I get the "status page" of any device ?]]'''

* '''[[What if the device is still unreachable after a serial rescue ?]]'''

* '''[[The device already has a password either I don't remember or I don't know, how do I erase it ?]]'''

* '''[[What is SonicIP?]]'''

* '''[[Redundancy]] - how do i use Barix devices for a high availabilty application'''

*'''SonicIP Voice - can I change this and record my own ?''' Yes, to do so follow this [[SonicIP Howto]]

* '''[[What is AutoIP, IPzator, etc.and how do I use them?]]'''

* '''[[Do the Barix products support Multicast and IGMP ?]]'''

* '''[[Do the Barix products support IPv6 ?]]'''

* '''[[I want to set up a local network with more than 250 devices, what do i have to do ?]]'''

* '''[[I want to do a broadcast over different subnets, is that possible ?]]'''

* '''[[Which port/s do your devices commonly use ?]]'''

* '''[[What does RTP stand for ?]]'''

* '''[[AND what does BRTP stand for ?]]'''

* '''[[How much latency should I expect in an Instreamer/Exstreamer setup using BTRP ?]]'''

* '''[[How do emergency messages work ?]]'''

== Audio FAQ ==

=== Questions related to audio formats in general ===
* '''[[What is the difference in using PCM MSB and PCM LSB?]]''' (e.g. in the STL application)

=== Instreamer/ Encoding related questions ===

* '''[[How are measured Input Peak Levels]]'''

* '''[[Can the Instreamer also encode WMA ?]]'''

* '''[[Can the Instreamer also encode AAC+ ?]]'''

* '''[[What kind of streams does the Instreamer produce ?]]'''

* '''[[May I configure the stream EXACTLY at 64 kps (or some other value) on Instreamer 100 ?]]'''

* '''[[How much bandwidth do I need to stream audio ?]]'''

* '''[[How many destinations can I stream to ?]]'''

* '''[[I have set up multiple shoutcast destinations on my Instreamer. Can I use different passwords for different streams?]]'''

* '''[[How do I set the Instreamer to feed streaming audio to a stream hosting company ?]]'''

* '''[[I want to play the stream of an Instreamer with Windows Media Player, but it does not work]]'''

* '''[[Is there a way to connect to the Barix Instreamer directly? We would like to get the audio from the device with as little lag as possible.]]'''

* '''How do I configure a Instreamer-Exstreamer audio connection within the same LAN ?''' Please read the [[Instreamer-Exstreamer How To]] guide.

* '''How do I configure a Instreamer-Exstreamer audio connection over the Internet (known as STL connection)?''' Please read the [[STL connection over Internet]] guide.

* '''When using the Instreamer 100 to encode / feed a Shoutcast Server, how do I insert Artist / Title / Station-name text ?''' Please read [[how to send metadata]]

* '''[[Can i distribute IP Audio over a SCA channel with an Instreamer ?]]'''

=== Exstreamer related questions ===

*'''[[How to use the Exstreamer 1000 as a PCM STL]] ?'''

*'''[[How do I play an AAC stream? What version of AAC do you support?]]'''

*'''How do I know what the LED blinking means ?''' Please find that information in the "Exstreamer Technical Manual". (Faster [[Green and Red LED]])

*'''[[Can I download audio files from a remote server to be played ?]]'''

*'''[[How do I configure the Exstreamer 100 to play files from a flash drive attached to the USB port when the Internet goes down ?]]'''

*'''[[How do I stream from a PC to an Exstreamer ?]]'''

*'''[[How can I monitor an Exstreamer ?]]'''

*'''What is the capacity of contact of the relay in an Exstreamer-1000 ?''' 24V - 0,5A

=== Annuncicom related questions ===

* '''[[Can I build an intercom system with Annuncicom?]]'''

* '''What are the ratings for the relay on the Annuncicom ?''' The ratings for the relay are: max 50V/1A

* '''[[Does the Annuncicom feature SIP functionality ?]]'''

* '''[[Is an Annuncicom 100 with standard firmware able to receive audio using RTP protocol ?]]'''

* '''[[How do I use the Annuncicom with Sureview Immix ?]]'''

=== IPAM related questions ===

* '''[[What is the difference between IPAM 200 and IPAM 300?]]'''

== Control FAQ ==

=== X8 related questions ===
* '''How do i update an X8 with the latest firmware ?''' You need a Barionet to do this. Please read a detailed howto [[X8-Update]]

=== Barionet related questions ===
* '''[[How do i read an I/O register using SNMP ?]]'''
* '''[[What is the typical Barionet Power Consumption ?]]'''

Back to [[Main Page#Support - FAQ & Troubleshooting]]

Main Page

2010-11-19T05:55:44Z

Jrietschel: /* Software Topics */

<big>'''Barix Wiki'''</big>

The Barix Wiki is maintained by Barix staff and users/community. Barix does try to keep the content accurate and error free, and we do review third party contributions, however, we can not guarantee everything is 100% accurate or up-to-date.
If you find any mistakes, errors etc. - please feel free to correct them !

== Barix Newsletter ==

[http://newsletter.barix.com/public/archive.php Click here to read the Barix newsletters.]

== Products ==
=== Audio - Devices and accessories ===
* [[Product Matrix]] - List of HW capabilities versus SW features
* [[Exstreamer 100]] - General Purpose Network Audio Decoder
* [[Exstreamer 110]] - Network Audio Decoder with advanced features - Decodes AAC+
* [[Exstreamer 200]] - Network Audio Decoder with built-in 2x25W class-D amplifier
* [[Exstreamer 1000]] - High Quality Network Audio Encoder/Decoder with symmetric Audio interfaces and AES/EBU
* [[Instreamer 100]] - General Purpose Network Audio Encoder
* [[Annuncicom 100]] - General Purpose Bidirectional Network Audio Device with I/O
* [[Annuncicom 200]] - Network Audio Device suitable for intercom/paging applications with 8W output amplifier and PoE
* [[Annuncicom 1000]] - High End Network Audio Device with balanced audio interfaces and supervised contact closures
* [[Radiobox]] - Radiobox and "Radiobox Pro" - Barix products ?
* [[IPAM 100]]- Embedded IP audio module for OEM with dual network and multiple serial interfaces
* [[IPAM 200 / IPAM 300]]- Embedded IP audio module for OEM (decoder only)
* [[PS16]] - Multifunctional digital desktop paging station PS16
* [[VSC]] - Volume Source Control accessory

=== Automation and Control - Devices and accessories ===
* [[Automation and Control Product Matrix]] - List of HW capabilities versus SW features
* [[Barionet]] - General Purpose IP Automation Controller with SNMP and Modbus/TCP support, fully programmable. Various I/O capabilities
* [[Barionet 50]] - Low Cost IP Automation Controller with contact closure inputs, relay outputs, serial ports and Dallas Onewire interface
* [[Barionet 200]] - Advanced IP Automation Controller with 16bit analog inputs, analog outputs, RTC and USB flash drive support

* [[Defconlock]] - This is an application specific Barionet, preloaded with an Access Control application (app also separately downloadable)
* [[Barix TS]] - onewire temperature sensors

* [[Barix X8]] - multipurpose RS-485 I/O Interface

* [[Barimon]] - web tool for collecting data from Barix devices: http://www.barimon.net/

== Applications ==
Barix products can be used in a vast variety of applications and markets. Below links bring you to pages which describe applications, which products to use etc
* [[Automation Applications]] - this includes data conversion, collection, remote managment and monitoring (non-audio) applications
* [[Broadcast Applications]] - Applications in the Broadcast Industry such as STL, internet radio, monitoring
* [[General Audio Distribution Applications]] - distribution of audio channels in hotels, over the internet, homes, amusement parks etc
* [[Alarm Applications]] - Use of the Barix products in emergency alerting applications
* [[SIP Applications]] - Use of the Barix products with SIP protocol for SIP speaker, intercom, phone applications
* [[Crestron Integration]] - integrating audio over IP with Crestron touchpanels
* [[IP Intercom]] - a general description and Intercom Applications
* [[Rebroadcasting Application]] - what does it do ?
* [[Messaging / Music on Hold Application from MOH Technology]]
* [[Scheduling of Audio or commands]]

== Hardware Topics ==
* [[Software/Hardware compatibility matrix]]
* [[USB device compatibility list]]
* [[USB and IPAM layout rules]]
* [[Microphones]]

== Software Topics ==

* [[General Topics]]
* [[Protocols used in Barix Products]]
* [[Streaming Client]]
* [[Streaming Client with USB encryption for Digital Rights Management]]
* [[Freeware from Barix]]
* [[BCL Topics]]
* [[Ethersound]]
* [[IP Audio Delay]]
* [[RTP Buffering - Frame Based Buffering]]
* [[SIP Applications]]
* [[VAcard PC software]]
* [[Redundancy]]

== Support - FAQ & Troubleshooting ==

* [[FAQ]] - general questions, sections about audio and control products

* [[Troubleshooting]]

* [[Reflector]]

== Sales & Marketing ==

== Some useful links for using the Wiki ==
Consult the [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.

=== Getting started ===
* [http://www.mediawiki.org/wiki/Manual:Configuration_settings Configuration settings list]
* [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ]
* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]

SIP Paging

2010-10-26T10:39:19Z

Jrietschel:

== SIP Paging applications with Barix devices ==

Barix IP Audio devices are ideal products to extend a SIP based phone system (PBX) such as Cisco Callmanager, Asterisk or OpenSER with paging functionalities. 
 
All Barix Exstreamer and Annuncicom devices can be loaded with the SIP firmware (which is a free download from the website). Once this firmware is loaded, the devices provide a functionality similar to a specialized phone.
 

For paging applications, an Exstreamer (output only) device suffices. 
The device can be programmed to auto-answer an incoming phone call, activate a relay with call reception (to activate a paging amplifier, for example), and output the call audio received through its analog output. Depending on the device, you have a choice of line level, 600Ohm balanced or even 2W, 8W or 2x25W amplified output, suitable to directly drive overhead speakers.
Some device models (Exstreamer 110/120/500, Annuncicom 100,200,1000) provide at least one contact closure output (relay). 
These contact closure outputs (up to 8 with the Annuncicom 1000) can be used for zone control, assuming that the SIP Paging gateway (Barix device with SIP firmware loaded) is connected to a traditional paging amplifier, which has inputs with which zones can be selected.
Details on how (as an example) an Asterisk PBX is configured to drive the Zone Control relays on an Annuncicom 1000 are in this wiki article: [[Asterix_Server_configuration_for_Relay_control]] 
 
Other PBX systems should work similar, and you can always control the relays even in-call by issuing certain commands to the device (common speak, you would say via DTMF, technically, button presses are typically delivered using SIP INfo or RFC 2833 encapsulation). Details are, again, in the article referred to above.

So .. Barix devices are ideal SIP Paging and Intercom devices, useable in a vast range of applications.

SIP Paging

2010-10-26T10:37:08Z

Jrietschel: New page: == SIP Paging applications with Barix devices == Barix IP Audio devices are ideal products to extend a SIP based phone system (PBX) such as Cisco Callmanager, Asterisk or OpenSER with pag...

== SIP Paging applications with Barix devices ==

Barix IP Audio devices are ideal products to extend a SIP based phone system (PBX) such as Cisco Callmanager, Asterisk or OpenSER with paging functionalities. 
 
All Barix Exstreamer and Annuncicom devices can be loaded with the SIP firmware (which is a free download from the website). Once this firmware is loaded, the devices provide a functionality similar to a specialized phone.
 

For paging applications, an Exstreamer (output only) device suffices. 
The device can be programmed to auto-answer an incoming phone call, activate a relay with call reception (to activate a paging amplifier, for example), and output the call audio received through its analog output. Depending on the device, you have a choice of line level, 600Ohm balanced or even 2W, 8W or 2x25W amplified output, suitable to directly drive overhead speakers.
Some device models (Exstreamer 110/120/500, Annuncicom 100,200,1000) provide at least one contact closure output (relay). 
These contact closure outputs (up to 8 with the Annuncicom 1000) can be used for zone control, assuming that the SIP Paging gateway (Barix device with SIP firmware loaded) is connected to a traditional paging amplifier, which has inputs with which zones can be selected.
Details on how (as an example) an Asterisk PBX is configured to drive the Zone Control relays on an Annuncicom 1000 are in this article: 
 
Other PBX systems should work similar, and you can always control the relays even in-call by issuing certain commands to the device (common speak, you would say via DTMF, technically, button presses are typically delivered using SIP INfo or RFC 2583 encapsulation). Details are, again, in the article referred to above.

So .. Barix devices are ideal SIP Paging and Intercom devices, useable in a vast range of applications.

Asterix Server configuration for Relay control

2010-10-26T10:26:29Z

Jrietschel: /* Example configuration of Asterix Server for controlling Relays on Annuncicom SIP Client */

==Example configuration of Asterix Server for controlling Relays on Annuncicom SIP Client==

Here is the actual configuration as a showcase of our company Asterisk server. We use two different extensions, reachable from even outside, which connect to an Annuncicom 1000 and select/deselect the relays at connnection establishment.
The commands sent (via SIP INFO/RFC2833) are just examples, the complete set is documented with the SIP Client firmware.

In the example below, extension 9999 is an Annuncicom 1000, and by dialling +4143xxxxxxx from external phone line, you will be connected to the Annuncicom and all relays will be reset (off - value 0), in the second line, if you dial +4143xxxxxxy, right after connection initiation, relays 1+2 (bit 0 and 1, value 3 in decimal) will be set to on.

exten => 043xxxxxxx,1,Dial(SIP/9999,10,D(#2*0*)) ; can be reached from external
exten => 043xxxxxxy,1,Dial(SIP/9999,10,D(#2*3*)) ; can be reached from external

Of course, you can also send such commands (#2*7* for example to set relay 1,2,3) while the connection is established from the calling phone, if it supports DTMF and all handling of the incoming phone is set up correctly in Asterisk (that is beyond our scope, standard Asterisk docs explain that well).

AND, sure, you can hide the relay selection from the user also by setting up dial-able extensions within Asterisk which use the same target and just do the relay selection. There is no difference between internal and external extensions in that sense in Asterisk.
Other SIP based systems work similar.

Can i distribute IP Audio over a SCA channel with an Instreamer ?

2010-09-17T16:58:58Z

Jrietschel:

We have been asked if an SCA channel could be used to route traffic generated by an Instreamer via an FM station. 

Unfortunately, the quick, general answer is '''NO''', this is impossible .. and here is the technical explanation: 
An SCA channel, which is a 5kHz bandwidth sub-carrier on an analog FM station transmitter, allows transport of an audio signal in addition to the "standard" stereo signal which is received by the standard FM receivers. Such an SCA channel uses an otherwised unused part of the FM station bandwidth. Details you can google on the internet. 
Traditionally, bandwidth-limited audio transmission technologies (like the plain old analog telephone system) have been used to carry digital data by using modems to convert serial data streams into audible signals which can be transmitted over a (voice) audio channel. 
A 5kHz bandwidth sounds like it could be used like a phone line - right ? 

Well, principially, that is possible. You CAN use a modem of some sort to encode a serial data stream and transmit it via an SCA channel, this has been done since at least 25 years now. BUT: the bitrate you can achieve with a one-way connection is very limited (according to Shannon's theorems, it is based on bandwidth and snr, a normal phone line can not carry more than roughly 30kbps in the optimum case). 
Any promises of "higher" bitrates (like 33.6k, 56k modems etc) use compression techniques and typically need 2-way communications. If you would want to transmit an MP3 encoded stream, for example, you would not be able to compress much on the data stream, which means these modems would not deliver 56k .. 
 
In any case, to carry IP (network) data over the SCA channel, you can '''NOT''' directly connect the network connector to the SCA channel encoder ! You will need a router and a modem to connect in between. The router serialized the network packets (arriving with 10Mbps or 100MBps speed), and sends them via a (slower) serial link, into the modem, which converts the serial stream to an audible signal, which then can be put into the SCA channel. The receiver end uses the inverse chain, a modem receives the SCA audio channel, converts to a serial stream, which is then put into a router to recreate IP/network traffic. 
 
All good - so why can't you use an Instreamer and Exstreamer with this ? 
Well - the achievable bitrates over the SCA channel will be in the range of 9600 baud to maybe 19200 or (i guess absolute max) 28800 kbps. That is enough to get contact closure information or maybe a short text (title information etc) over the SCA channel, even if encapsulated into IP (which adds a lot of overhead to the raw data !), but for an IP Audio stream, encoded by an Instreamer, which requires at least 40kbps plus overhead, this is much too little. 
Satellites provide much higher bitrates for aux channels, so a similar application might work very well with a satellite system (but i have not done any research into this).

So - bottom line, if you want to carry anything via IP and distribute via an FM SCA channel, you will face these limitations:
* very low achievable bitrate
* one-way connection only (unidirectional from transmitter to receivers), no retries etc
* suitable for contact closures or small text messages
* not suitable for an IP Audio stream using MP3 or PCM or other "standard" codecs.
 
There are specialized encoders/codecs for low quality, very low bandwidth algorithms (military stuff uses down to 1200bps, cellphones use often 9600baud), so you could probably encode an audio stream with very low quality to send it over an IP link using 28.800 baud modems, but definitely with inferior quality than feeding the audio signal itself.
 
 
Sep. 17, 2010 JR

Can i distribute IP Audio over a SCA channel with an Instreamer ?

2010-09-17T16:52:30Z

Jrietschel: discussion about carrying IP Audio (and control) over an FM SCA channel

We have been asked if a SCA channel could be used to route traffic generated by an Instreamer via an FM station. 

Unfortunately, the quick, general answer is '''NO''', this is impossible .. and here is the technical explanation: 
A SCA channel, which is a 5kHz bandwidth sub-carrier on an analog FM station transmitter, allows transport of an audio signal in addition to the "standard" stereo signal which is received by the standard FM receivers. Such a SCA channel uses an otherwised unused part of the FM station bandwidth. Details you can google on the internet. 
Traditionally, bandwidth-limited audio transmission technologies (like the plain old analog telephone system) have been used to carry digital data by using modems to convert serial data streams into audible signals which can be transmitted over a (voice) audio channel. 
A 5kHz bandwidth sounds like it could be used like a phone line - right ? 

Well, principially, that is possible. You CAN use a modem of some sort to encode a serial data stream and transmit it via an SCA channel, this has been done since at least 25 years now. BUT: the bitrate you can achieve with a one-way connection is very limited (according to Shannon's theorems, it is based on bandwidth and snr, a normal phone line can not carry more than roughly 30kbps in the optimum case). 
Any promises of "higher" bitrates (like 33.6k, 56k modems etc) use compression techniques and typically need 2-way communications. If you would want to transmit an MP3 encoded stream, for example, you would not be able to compress much on the data stream, which means these modems would not deliver 56k .. 
 
In any case, to carry IP (network) data over the SCA channel, you can '''NOT''' directly connect the network connector to the SCA channel encoder ! You will need a router and a modem to connect in between. The router serialized the network packets (arriving with 10Mbps or 100MBps speed), and sends them via a (slower) serial link, into the modem, which converts the serial stream to an audible signal, which then can be put into the SCA channel. The receiver end uses the inverse chain, a modem receives the SCA audio channel, converts to a serial stream, which is then put into a router to recreate IP/network traffic. 
 
All good - so why can't you use an Instreamer and Exstreamer with this ? 
Well - the achievable bitrates over the SCA channel will be in the range of 9600 baud to maybe 19200 or (i guess absolute max) 28800 kbps. That is enough to get contact closure information or maybe a short text (title information etc) over the SCA channel, even if encapsulated into IP (which adds a lot of overhead to the raw data !), but for an IP Audio stream, encoded by an Instreamer, which requires at least 40kbps plus overhead, this is much too little. 
Satellites provide much higher bitrates for aux channels, so a similar application might work very well with a satellite system (but i have not done any research into this).

So - bottom line, if you want to carry anything via IP and distribute via an FM SCA channel, you will face these limitations:
* very low achievable bitrate
* one-way connection only (unidirectional from transmitter to receivers), no retries etc
* suitable for contact closures or small text messages
* not suitable for an IP Audio stream using MP3 or PCM or other "standard" codecs.
 
There are specialized encoders/codecs for low quality, very low bandwidth algorithms (military stuff uses down to 1200bps, cellphones use often 9600baud), so you could probably encode an audio stream with very low quality to send it over an IP link using 28.800 baud modems, but definitely with inferior quality than feeding the audio signal itself.
 
 
Sep. 17, 2010 JR

FAQ

2010-09-17T16:19:27Z

Jrietschel: /* Instreamer/ Encoding related questions */

== General questions - IP, Addressing, Multicast etc ==

* '''[[Are there any known security vulnerabilities with Barix devices]]'''

* '''[[So, I have purchased an Instreamer and an Exstreamer. And now what?]]'''

* '''[[How do the devices get their IP address ?]]'''

* '''[[What if my routers don't have a fix IP address from the ISP (Internet service provider) ?]]'''

* ''' How do i connect a Barix device to HSPDA, UMTS, CDMA, EVDO, wireless networks ? Please see [[Connecting to 3G Networks]]'''

* '''Ho do I do a web update of a device ? Please see [[FW Update]]'''

* '''[[How do I set the device back to factory defaults ?]]'''

* '''How do I perform a "Serial Rescue" of the device if it becomes unreachable ? Please see [[FW Update]]'''

* '''[[How do I get the "status page" of any device ?]]'''

* '''[[What if the device is still unreachable after a serial rescue ?]]'''

* '''[[The device already has a password either I don't remember or I don't know, how do I erase it ?]]'''

* '''[[What is SonicIP?]]'''

*'''SonicIP Voice - can I change this and record my own ?''' Yes, to do so follow this [[SonicIP Howto]]

* '''[[What is AutoIP, IPzator, etc.and how do I use them?]]'''

* '''[[Do the Barix products support Multicast and IGMP ?]]'''

* '''[[Do the Barix products support IPv6 ?]]'''

* '''[[I want to set up a local network with more than 250 devices, what do i have to do ?]]'''

* '''[[I want to do a broadcast over different subnets, is that possible ?]]'''

* '''[[Which port/s do your devices commonly use ?]]'''

* '''[[What does RTP stand for ?]]'''

* '''[[AND what does BRTP stand for ?]]'''

* '''[[How much latency should I expect in an Instreamer/Exstreamer setup using BTRP ?]]'''

* '''[[How do emergency messages work ?]]'''

== Audio FAQ ==

=== Questions related to audio formats in general ===
* '''[[What is the difference in using PCM MSB and PCM LSB?]]''' (e.g. in the STL application)

=== Instreamer/ Encoding related questions ===

* '''[[How are measured Input Peak Levels]]'''

* '''[[Can the Instreamer also encode WMA ?]]'''

* '''[[Can the Instreamer also encode AAC+ ?]]'''

* '''[[What kind of streams does the Instreamer produce ?]]'''

* '''[[May I configure the stream EXACTLY at 64 kps (or some other value) on Instreamer 100 ?]]'''

* '''[[How much bandwidth do I need to stream audio ?]]'''

* '''[[How many destinations can I stream to ?]]'''

* '''[[I have set up multiple shoutcast destinations on my Instreamer. Can I use different passwords for different streams?]]'''

* '''[[How do I set the Instreamer to feed streaming audio to a stream hosting company ?]]'''

* '''[[I want to play the stream of an Instreamer with Windows Media Player, but it does not work]]'''

* '''[[Is there a way to connect to the Barix Instreamer directly? We would like to get the audio from the device with as little lag as possible.]]'''

* '''How do I configure a Instreamer-Exstreamer audio connection within the same LAN ?''' Please read the [[Instreamer-Exstreamer How To]] guide.

* '''How do I configure a Instreamer-Exstreamer audio connection over the Internet (known as STL connection)?''' Please read the [[STL connection over Internet]] guide.

* '''When using the Instreamer 100 to encode / feed a Shoutcast Server, how do I insert Artist / Title / Station-name text ?''' Please read [[how to send metadata]]

* '''[[Can i distribute IP Audio over a SCA channel with an Instreamer ?]]'''

=== Exstreamer related questions ===

*'''[[How to use the Exstreamer 1000 as a PCM STL]] ?'''

*'''[[How do I play an AAC stream? What version of AAC do you support?]]'''

*'''How do I know what the LED blinking means ?''' Please find that information in the "Exstreamer Technical Manual". (Faster [[Green and Red LED]])

*'''[[Can I download audio files from a remote server to be played ?]]'''

*'''[[How do I configure the Exstreamer 100 to play files from a flash drive attached to the USB port when the Internet goes down ?]]'''

*'''[[How do I stream from a PC to an Exstreamer ?]]'''

*'''[[How can I monitor an Exstreamer ?]]'''

*'''What is the capacity of contact of the relay in an Exstreamer-1000 ?''' 24V - 0,5A

=== Annuncicom related questions ===

* '''[[Can I build an intercom system with Annuncicom?]]'''

* '''What are the ratings for the relay on the Annuncicom ?''' The ratings for the relay are: max 50V/1A

* '''[[Does the Annuncicom feature SIP functionality ?]]'''

* '''[[Is an Annuncicom 100 with standard firmware able to receive audio using RTP protocol ?]]'''

=== IPAM related questions ===

* '''[[What is the difference between IPAM 200 and IPAM 300?]]'''

== Control FAQ ==

=== X8 related questions ===
* '''How do i update an X8 with the latest firmware ?''' You need a Barionet to do this. Please read a detailed howto [[X8-Update]]

=== Barionet related questions ===
* '''[[How do i read an I/O register using SNMP ?]]'''
* '''[[What is the typical Barionet Power Consumption ?]]'''

Back to [[Main Page#Support - FAQ & Troubleshooting]]

FAQ

2010-09-17T16:19:09Z

Jrietschel: /* Instreamer/ Encoding related questions */

== General questions - IP, Addressing, Multicast etc ==

* '''[[Are there any known security vulnerabilities with Barix devices]]'''

* '''[[So, I have purchased an Instreamer and an Exstreamer. And now what?]]'''

* '''[[How do the devices get their IP address ?]]'''

* '''[[What if my routers don't have a fix IP address from the ISP (Internet service provider) ?]]'''

* ''' How do i connect a Barix device to HSPDA, UMTS, CDMA, EVDO, wireless networks ? Please see [[Connecting to 3G Networks]]'''

* '''Ho do I do a web update of a device ? Please see [[FW Update]]'''

* '''[[How do I set the device back to factory defaults ?]]'''

* '''How do I perform a "Serial Rescue" of the device if it becomes unreachable ? Please see [[FW Update]]'''

* '''[[How do I get the "status page" of any device ?]]'''

* '''[[What if the device is still unreachable after a serial rescue ?]]'''

* '''[[The device already has a password either I don't remember or I don't know, how do I erase it ?]]'''

* '''[[What is SonicIP?]]'''

*'''SonicIP Voice - can I change this and record my own ?''' Yes, to do so follow this [[SonicIP Howto]]

* '''[[What is AutoIP, IPzator, etc.and how do I use them?]]'''

* '''[[Do the Barix products support Multicast and IGMP ?]]'''

* '''[[Do the Barix products support IPv6 ?]]'''

* '''[[I want to set up a local network with more than 250 devices, what do i have to do ?]]'''

* '''[[I want to do a broadcast over different subnets, is that possible ?]]'''

* '''[[Which port/s do your devices commonly use ?]]'''

* '''[[What does RTP stand for ?]]'''

* '''[[AND what does BRTP stand for ?]]'''

* '''[[How much latency should I expect in an Instreamer/Exstreamer setup using BTRP ?]]'''

* '''[[How do emergency messages work ?]]'''

== Audio FAQ ==

=== Questions related to audio formats in general ===
* '''[[What is the difference in using PCM MSB and PCM LSB?]]''' (e.g. in the STL application)

=== Instreamer/ Encoding related questions ===

* '''[[How are measured Input Peak Levels]]'''

* '''[[Can the Instreamer also encode WMA ?]]'''

* '''[[Can the Instreamer also encode AAC+ ?]]'''

* '''[[What kind of streams does the Instreamer produce ?]]'''

* '''[[May I configure the stream EXACTLY at 64 kps (or some other value) on Instreamer 100 ?]]'''

* '''[[How much bandwidth do I need to stream audio ?]]'''

* '''[[How many destinations can I stream to ?]]'''

* '''[[I have set up multiple shoutcast destinations on my Instreamer. Can I use different passwords for different streams?]]'''

* '''[[How do I set the Instreamer to feed streaming audio to a stream hosting company ?]]'''

* '''[[I want to play the stream of an Instreamer with Windows Media Player, but it does not work]]'''

* '''[[Is there a way to connect to the Barix Instreamer directly? We would like to get the audio from the device with as little lag as possible.]]'''

* '''How do I configure a Instreamer-Exstreamer audio connection within the same LAN ?''' Please read the [[Instreamer-Exstreamer How To]] guide.

* '''How do I configure a Instreamer-Exstreamer audio connection over the Internet (known as STL connection)?''' Please read the [[STL connection over Internet]] guide.

* '''When using the Instreamer 100 to encode / feed a Shoutcast Server, how do I insert Artist / Title / Station-name text ?''' Please read [[how to send metadata]]

* '''[[Can i distribute IP Audio over SCA with an Instreamer ?]]'''

=== Exstreamer related questions ===

*'''[[How to use the Exstreamer 1000 as a PCM STL]] ?'''

*'''[[How do I play an AAC stream? What version of AAC do you support?]]'''

*'''How do I know what the LED blinking means ?''' Please find that information in the "Exstreamer Technical Manual". (Faster [[Green and Red LED]])

*'''[[Can I download audio files from a remote server to be played ?]]'''

*'''[[How do I configure the Exstreamer 100 to play files from a flash drive attached to the USB port when the Internet goes down ?]]'''

*'''[[How do I stream from a PC to an Exstreamer ?]]'''

*'''[[How can I monitor an Exstreamer ?]]'''

*'''What is the capacity of contact of the relay in an Exstreamer-1000 ?''' 24V - 0,5A

=== Annuncicom related questions ===

* '''[[Can I build an intercom system with Annuncicom?]]'''

* '''What are the ratings for the relay on the Annuncicom ?''' The ratings for the relay are: max 50V/1A

* '''[[Does the Annuncicom feature SIP functionality ?]]'''

* '''[[Is an Annuncicom 100 with standard firmware able to receive audio using RTP protocol ?]]'''

=== IPAM related questions ===

* '''[[What is the difference between IPAM 200 and IPAM 300?]]'''

== Control FAQ ==

=== X8 related questions ===
* '''How do i update an X8 with the latest firmware ?''' You need a Barionet to do this. Please read a detailed howto [[X8-Update]]

=== Barionet related questions ===
* '''[[How do i read an I/O register using SNMP ?]]'''
* '''[[What is the typical Barionet Power Consumption ?]]'''

Back to [[Main Page#Support - FAQ & Troubleshooting]]

SIP with Siemens Gigaset

2010-08-23T09:34:35Z

Jrietschel: New page: This page content is in the process of being created. Please contact Barix through "support@barix.com" if you need the information immediately.

This page content is in the process of being created.

Please contact Barix through "support@barix.com" if you need the information immediately.

SIP Applications

2010-08-23T09:34:00Z

Jrietschel:

* [[SIP Paging]] - Barix Exstreamer is ideal as a SIP paging gateway or to set up direct "SIP paging speakers" - even with PoE and high output power
* [[SIP Intercom]] - a simple Intercom solution using standard SIP with Barix products
* [[SIP OnHold Input]] - how to use an Instreamer or Annuncicom as an input source into a SIP based PBX for background music
* [[SIP BGM Input]] - very similar to the above application, an Annuncicom or Instreamer can serve as a source of a constant audio feed
* [[SIP with Siemens Gigaset]] - how to configure an Annuncicom so it works as a Door Station for a Siemens IP Phone such as the S685IP

Back to [[Main Page#Applications]]

Main Page

2010-08-23T09:32:46Z

Jrietschel: /* Software Topics */

<big>'''Barix Wiki'''</big>

The Barix Wiki is maintained by Barix staff and users/community. Barix does try to keep the content accurate and error free, and we do review third party contributions, however, we can not guarantee everything is 100% accurate or up-to-date.
If you find any mistakes, errors etc. - please feel free to correct them !

== Barix Newsletter ==

[http://newsletter.barix.com/public/archive.php Click here to read the Barix newsletters.]

== Products ==
=== Audio - Devices and accessories ===
* [[Product Matrix]] - List of HW capabilities versus SW features
* [[Exstreamer 100]] - General Purpose Network Audio Decoder
* [[Exstreamer 110]] - Network Audio Decoder with advanced features - Decodes AAC+
* [[Exstreamer 200]] - Network Audio Decoder with built-in 2x25W class-D amplifier
* [[Exstreamer 1000]] - High Quality Network Audio Encoder/Decoder with symmetric Audio interfaces and AES/EBU
* [[Instreamer 100]] - General Purpose Network Audio Encoder
* [[Annuncicom 100]] - General Purpose Bidirectional Network Audio Device with I/O
* [[Annuncicom 200]] - Network Audio Device suitable for intercom/paging applications with 8W output amplifier and PoE
* [[Annuncicom 1000]] - High End Network Audio Device with balanced audio interfaces and supervised contact closures
* [[Radiobox]] - Radiobox and "Radiobox Pro" - Barix products ?
* [[IPAM 100]]- Embedded IP audio module for OEM with dual network and multiple serial interfaces
* [[IPAM 200 / IPAM 300]]- Embedded IP audio module for OEM (decoder only)
* [[PS16]] - Multifunctional digital desktop paging station PS16
* [[VSC]] - Volume Source Control accessory

=== Automation and Control - Devices and accessories ===
* [[Barionet]] - General Purpose IP Automation Controller with SNMP and Modbus/TCP support, fully programmable. Various I/O capabilities
* [[Barionet 50]] - Low Cost IP Automation Controller with contact closure inputs, relay outputs, serial ports and Dallas Onewire interface
* [[Barionet 200]] - Advanced IP Automation Controller with 16bit analog inputs, analog outputs, RTC and USB flash drive support

* [[Defconlock]] - This is an application specific Barionet, preloaded with an Access Control application (app also separately downloadable)
* [[Barix TS]] - onewire temperature sensors

* [[Barix X8]] - multipurpose RS-485 I/O Interface

* [[Barimon]] - web tool for collecting data from Barix devices: http://www.barimon.net/

== Applications ==
Barix products can be used in a vast variety of applications and markets. Below links bring you to pages which describe applications, which products to use etc
* [[Automation Applications]] - this includes data conversion, collection, remote managment and monitoring (non-audio) applications
* [[Broadcast Applications]] - Applications in the Broadcast Industry such as STL, internet radio, monitoring
* [[General Audio Distribution Applications]] - distribution of audio channels in hotels, over the internet, homes, amusement parks etc
* [[Alarm Applications]] - Use of the Barix products in emergency alerting applications
* [[SIP Applications]] - Use of the Barix products with SIP protocol for SIP speaker, intercom, phone applications
* [[Crestron Integration]] - integrating audio over IP with Crestron touchpanels
* [[IP Intercom]] - a general description and Intercom Applications
* [[Rebroadcasting Application]] - what does it do ?
* [[Messaging / Music on Hold Application from MOH Technology]]

== Hardware Topics ==
* [[Software/Hardware compatibility matrix]]
* [[USB device compatibility list]]
* [[USB and IPAM layout rules]]
* [[Microphones]]

== Software Topics ==

* [[General Topics]]
* [[Protocols used in Barix Products]]
* [[Streaming Client]]
* [[Streaming Client with USB encryption for Digital Rights Management]]
* [[Freeware from Barix]]
* [[BCL Topics]]
* [[Ethersound]]
* [[IP Audio Delay]]
* [[RTP Buffering - Frame Based Buffering]]
* [[SIP Applications]]

== Support - FAQ & Troubleshooting ==

* [[FAQ]] - general questions, sections about audio and control products

* [[Troubleshooting]]

== Sales & Marketing ==

== Some useful links for using the Wiki ==
Consult the [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.

=== Getting started ===
* [http://www.mediawiki.org/wiki/Manual:Configuration_settings Configuration settings list]
* [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ]
* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]

IP Audio Delay

2010-04-12T06:10:06Z

Jrietschel:

Whenever you transport audio over an IP network - that is true for every vendor and every technology, you will incur a delay. That is unavoidable. Why ? This page will explain the general concept of how Audio over IP works, and explain specifically the reasons for an inherent delay.

CURRENTLY WORK IN PROGRESS - NEEDS TO BE REVIEWED

== Concept of Audio over IP ==
=== Sampling ===
To transmit Analog Audio over an IP Network, it needs to be sampled (a measure be taken) with the sample rate. These samples then can be handled in the digital domain and transferred over the network to the decoder, which ultimately will convert the samples back to an analog voltage on the audio output, accurate with the sample frequency.
The original signal as it was present at the input is reproduced on the output.

=== Sending every sample over the network ===
In theory, every sample could be directly sent as a block over the IP network with minimum delay, but doing this will generate a huge amount of traffic (48.000 blocks per second for 48khz sample rate) and bandwidth requirement (a min. ethernet frame is 60bytes, so you are actually using more than 23MBps if you do this) !

Ethersound does this, actually - all channel samples at a given timepoint (one per channel) go together in a frame on the network, one frame per sample set .. generating practically a constant network load of 100Mbps (not over IP, but over Ethernet).

For standard applications where the audio stream needs to coexist on the network with other services, something must be done to generate less network load

=== Collecting samples, sending packets ===
Let us assume the network load, expressed in number of packets per second, needs to be limited to no more than 100 (blocks per second). To achieve that, the device will need to to collect 10ms worth of samples before sending them out together in an IP block.

With a 48kHz sample frequency, that means 480 samples (960 bytes) have to be collected before the block can be sent. That is making perfect sense, as one Ethernet block can carry up to about 1400 bytes of Data.

=== Receiving and decoding ===

At the receiving end (the "Decoder"), a constant stream of samples at the sample frequency must be generated. To do this, the decoder always needs samples "in storage" it can use, if it ever runs out of samples to generate the stream, an "underrun" condition exists, which will cause dropouts and other issues. Consequently, a buffer of samples must be maintained, high enough so that it always is replenished before the D/A runs out of data.

== Delays introduced in the chain ==

=== Packetizing at the encoder ===
As already discussed above, to limit the bandwidth used to a reasonable level, samples must be collected and send as blocks to the destination, via the network. Here is the first delay. It is pretty obvious: The delay incurred, even with an optimum system performance, directly depends on the number of samples per block resp. blocks per second.
if 100 blocks per second is the target, 10ms of samples need to be collected, if 50 blocks per second are allowed, 20ms worth of samples need to be collected before they can be sent.

With MP3, not only is a frame of samples first collected (20..50ms, depending on quality setting), but the collected samples then, once complete, must be processed with computational intensive functions (DSP), which takes significant time (but average less than it took to collect the samples, otherwise the system cannot work reliably).

=== Processing at the encoder ===
While putting PCM samples in a packet and sending them does not really need resources, in the MP3 case, a significant delay is introduced in addition to the delay produced by "holding up" the samples to packetize them. Count in 20ms for MP3.

=== Network delay "in transit" ===

Now that a block is going to the network, some delay already is introduced (let's stick with the example, 10ms for PCM and 60ms for MP3). The block now needs to be sent over the network, potentially fighting with other traffic for bandwidth. On a local LAN, the delay will typically be quite low (msecs maybe), but beware .. if there is "sometimes" a fight over bandwidth/buffering in a switch or router, you may see average very low delays but PEAK delays could be substantially higher.
Why is that a problem ? Well .. the receiving side always needs to be fed with samples before its buffers run empty .. now, if there is a block delayed, let's say 30ms, the receiver must have buffers configured so that it can live with that delay before running into an error condition (empty buffer). The difference between the min. delay and the max. delay of a network block arriving at the decoder is commonly called "jitter". Jitter can be significant especially with Wifi networks, as there are invisible retries happening in a lower level protocol - you might see (ping command shows all this) an average delay of only 5ms, and zero block loss, but a max. delay of 200ms ... any device with a receive buffer configured of less than 200ms will mean that you will encur dropouts. period.

=== Buffers in the receiver ===
Now, let's take a close look at the decoding side. As already stated before, to maintain a constant, consistent stream of samples (which are then converted to an analog value and sent to the audio interface), buffering is a must. The buffers must be able and configured to hold as much data as necessary to cover/survive the longest possible "dry period" when no block comes in from the source, for whatever reason.
If (example above), the source sends a block every 10ms, very precise timing, and zero jitter is introduced by the network (an unlikely scenario), in theory a buffer of one frame is sufficient. When the block arrives from the network, it will be copied into the buffer (let's say, holding 480 samples, in our example with 10ms) and the output can start converting to analog. The buffer now drains, but right when it is getting to "empty", the next block comes in from our perfect encoder through the perfect network infrastructure.
That is, unfortuntately, not a real life scenario, jitter is always introduced somewhere on the way. A realistic setup uses a buffer holding several blocks.

=== Processing in the Receiver ===
Oh yes, and for MP3, you have to add another reason for delay at the decoder side. Once a frame is received, it cannot be output immediately, but it first needs to be decoded, which is resource intensive and can take several ms .. and there is a need for an output buffer for samples ...

=== Sample buffer for the D/A ===
The last addition of delay is not really necessary technology wise, but a fact in Barix devices. We use a Main CPU for network tasks and a DSP driving the D/A, which turns the samples back to analog audio. The DSP is necessary for MP3 (and AAC etc etc) decoding, for PCM it mainly works as a pass-through. The interface between the main CPU and the DSP also introduces a sample buffer at the DSP output side, which is counted in bytes, and can introduce quite significant delays for low bitrate/sample rate streams. Why ? Well, the buffer is counted in Bytes as i said, and let's assume for these examples here it is 2kBytes (2000 bytes), for a PCM 48kHz stream that means 96Bytes per ms, so roughly 20ms - but if you send a 8Khz PCM stream, you get 6x that delay.

== Conclusion ==
So, at the end you have several sources introducing delay, with the buffering for network jitter being often the most significant one, but a "base delay", depending on sample rate, encoding format etc is always present. As you can figure from the above examples, if you have the bandwidth, it often makes sense to configure higher sample rates and bitrate streams, as that will effectively lower the delay due to the fact that the constant (byte wise) buffers in the chain have a smaller through delay.

== Barix devices ==
One last comment, now specific to Barix devices: The Exstreamer 1xx and 2xx decoder devices use a DSP with ample buffering. There is reasons for that, not to be further detailed here. In contrast, the Exstreamer 1000 and the "to be announced monday at NAB" device (hint hint !) as well as all Annuncicom devices use a different DSP with lower buffers, and we are currently beta testing a DSP software patch which reduces the buffers much further to almost non-existing !
With the Exstreamer 1000 and the new device, you can currently achieve delays of below 50ms - the software has not been optimized for very low delay. However, with optimized software, you can get the delay down to well below 20ms - that has been proven in our labs (for a specific project). We are in the process to bring this down further, obviously (goal 5ms ?) this can only be done by sending many more blocks over the network, for example, one per ms - 1000 blocks per second .. ask your Wifi router what it thinks about that ..), so it needs optimized software.

IP Audio Delay

2010-04-12T06:09:06Z

Jrietschel:

Whenever you transport audio over an IP network - that is true for every vendor and every technology, you will incur a delay. That is unavoidable. Why ? This page will explain the general concept of how Audio over IP works, and explain specifically the reasons for an inherent delay.

CURRENTLY WORK IN PROGRESS - UNFINISHED

== Concept of Audio over IP ==
=== Sampling ===
To transmit Analog Audio over an IP Network, it needs to be sampled (a measure be taken) with the sample rate. These samples then can be handled in the digital domain and transferred over the network to the decoder, which ultimately will convert the samples back to an analog voltage on the audio output, accurate with the sample frequency.
The original signal as it was present at the input is reproduced on the output.

=== Sending every sample over the network ===
In theory, every sample could be directly sent as a block over the IP network with minimum delay, but doing this will generate a huge amount of traffic (48.000 blocks per second for 48khz sample rate) and bandwidth requirement (a min. ethernet frame is 60bytes, so you are actually using more than 23MBps if you do this) !

Ethersound does this, actually - all channel samples at a given timepoint (one per channel) go together in a frame on the network, one frame per sample set .. generating practically a constant network load of 100Mbps (not over IP, but over Ethernet).

For standard applications where the audio stream needs to coexist on the network with other services, something must be done to generate less network load

=== Collecting samples, sending packets ===
Let us assume the network load, expressed in number of packets per second, needs to be limited to no more than 100 (blocks per second). To achieve that, the device will need to to collect 10ms worth of samples before sending them out together in an IP block.

With a 48kHz sample frequency, that means 480 samples (960 bytes) have to be collected before the block can be sent. That is making perfect sense, as one Ethernet block can carry up to about 1400 bytes of Data.

=== Receiving and decoding ===

At the receiving end (the "Decoder"), a constant stream of samples at the sample frequency must be generated. To do this, the decoder always needs samples "in storage" it can use, if it ever runs out of samples to generate the stream, an "underrun" condition exists, which will cause dropouts and other issues. Consequently, a buffer of samples must be maintained, high enough so that it always is replenished before the D/A runs out of data.

== Delays introduced in the chain ==

=== Packetizing at the encoder ===
As already discussed above, to limit the bandwidth used to a reasonable level, samples must be collected and send as blocks to the destination, via the network. Here is the first delay. It is pretty obvious: The delay incurred, even with an optimum system performance, directly depends on the number of samples per block resp. blocks per second.
if 100 blocks per second is the target, 10ms of samples need to be collected, if 50 blocks per second are allowed, 20ms worth of samples need to be collected before they can be sent.

With MP3, not only is a frame of samples first collected (20..50ms, depending on quality setting), but the collected samples then, once complete, must be processed with computational intensive functions (DSP), which takes significant time (but average less than it took to collect the samples, otherwise the system cannot work reliably).

=== Processing at the encoder ===
While putting PCM samples in a packet and sending them does not really need resources, in the MP3 case, a significant delay is introduced in addition to the delay produced by "holding up" the samples to packetize them. Count in 20ms for MP3.

=== Network delay "in transit" ===

Now that a block is going to the network, some delay already is introduced (let's stick with the example, 10ms for PCM and 60ms for MP3). The block now needs to be sent over the network, potentially fighting with other traffic for bandwidth. On a local LAN, the delay will typically be quite low (msecs maybe), but beware .. if there is "sometimes" a fight over bandwidth/buffering in a switch or router, you may see average very low delays but PEAK delays could be substantially higher.
Why is that a problem ? Well .. the receiving side always needs to be fed with samples before its buffers run empty .. now, if there is a block delayed, let's say 30ms, the receiver must have buffers configured so that it can live with that delay before running into an error condition (empty buffer). The difference between the min. delay and the max. delay of a network block arriving at the decoder is commonly called "jitter". Jitter can be significant especially with Wifi networks, as there are invisible retries happening in a lower level protocol - you might see (ping command shows all this) an average delay of only 5ms, and zero block loss, but a max. delay of 200ms ... any device with a receive buffer configured of less than 200ms will mean that you will encur dropouts. period.

=== Buffers in the receiver ===
Now, let's take a close look at the decoding side. As already stated before, to maintain a constant, consistent stream of samples (which are then converted to an analog value and sent to the audio interface), buffering is a must. The buffers must be able and configured to hold as much data as necessary to cover/survive the longest possible "dry period" when no block comes in from the source, for whatever reason.
If (example above), the source sends a block every 10ms, very precise timing, and zero jitter is introduced by the network (an unlikely scenario), in theory a buffer of one frame is sufficient. When the block arrives from the network, it will be copied into the buffer (let's say, holding 480 samples, in our example with 10ms) and the output can start converting to analog. The buffer now drains, but right when it is getting to "empty", the next block comes in from our perfect encoder through the perfect network infrastructure.
That is, unfortuntately, not a real life scenario, jitter is always introduced somewhere on the way. A realistic setup uses a buffer holding several blocks.

=== Processing in the Receiver ===
Oh yes, and for MP3, you have to add another reason for delay at the decoder side. Once a frame is received, it cannot be output immediately, but it first needs to be decoded, which is resource intensive and can take several ms .. and there is a need for an output buffer for samples ...

=== Sample buffer for the D/A ===
The last addition of delay is not really necessary technology wise, but a fact in Barix devices. We use a Main CPU for network tasks and a DSP driving the D/A, which turns the samples back to analog audio. The DSP is necessary for MP3 (and AAC etc etc) decoding, for PCM it mainly works as a pass-through. The interface between the main CPU and the DSP also introduces a sample buffer at the DSP output side, which is counted in bytes, and can introduce quite significant delays for low bitrate/sample rate streams. Why ? Well, the buffer is counted in Bytes as i said, and let's assume for these examples here it is 2kBytes (2000 bytes), for a PCM 48kHz stream that means 96Bytes per ms, so roughly 20ms - but if you send a 8Khz PCM stream, you get 6x that delay.

== Conclusion ==
So, at the end you have several sources introducing delay, with the buffering for network jitter being often the most significant one, but a "base delay", depending on sample rate, encoding format etc is always present. As you can figure from the above examples, if you have the bandwidth, it often makes sense to configure higher sample rates and bitrate streams, as that will effectively lower the delay due to the fact that the constant (byte wise) buffers in the chain have a smaller through delay.

== Barix devices ==
One last comment, now specific to Barix devices: The Exstreamer 1xx and 2xx decoder devices use a DSP with ample buffering. There is reasons for that, not to be further detailed here. In contrast, the Exstreamer 1000 and the "to be announced monday at NAB" device (hint hint !) as well as all Annuncicom devices use a different DSP with lower buffers, and we are currently beta testing a DSP software patch which reduces the buffers much further to almost non-existing !
With the Exstreamer 1000 and the new device, you can currently achieve delays of below 50ms - the software has not been optimized for very low delay. However, with optimized software, you can get the delay down to well below 20ms - that has been proven in our labs (for a specific project). We are in the process to bring this down further, obviously (goal 5ms ?) this can only be done by sending many more blocks over the network, for example, one per ms - 1000 blocks per second .. ask your Wifi router what it thinks about that ..), so it needs optimized software.

IP Audio Delay

2010-04-12T05:30:05Z

Jrietschel:

Whenever you transport audio over an IP network - that is true for every vendor and every technology, you will incur a delay. That is unavoidable. Why ? This page will explain the general concept of how Audio over IP works, and explain specifically the reasons for an inherent delay.
CURRENTLY WORK IN PROGRESS - COME BACK in 2 hours ..

== Concept of Audio over IP ==
To transmit Analog Audio over an IP Network, it needs to be sampled (a measure be taken) with the sample rate. These samples then can be handled in the digital domain and transferred over the network to the decoder, which ultimately will convert the samples back to an analog voltage on the audio output, accurate with the sample frequency.
The original signal as it was present at the input is reproduced on the output.

=== Sending every sample over the network immediately ===
In theory, every sample could be directly sent as a block over the IP network with minimum delay, but doing this will generate a huge amount of traffic (48.000 blocks per second for 48khz sample rate) and bandwidth requirement (a min. ethernet frame is 60bytes, so you are actually using more than 23MBps if you do this) !

Ethersound does this, actually - all channel samples at a given timepoint (one per channel) go together in a frame on the network, one frame per sample set .. generating practically a constant network load of 100Mbps (not over IP, but over Ethernet).

For standard applications where the audio stream needs to coexist on the network with other services, something must be done to generate less network load

=== Collecting Samples, sending Packets ===
Let us assume the network load, expressed in number of packets per second, needs to be limited to no more than 100 (blocks per second). To achieve that, the device will need to to collect 10ms worth of samples before sending them out together in an IP block.

With a 48kHz sample frequency, that means 480 samples (960 bytes) have to be collected before the block can be sent. That is making perfect sense, as one Ethernet block can carry up to about 1400 bytes of Data.

=== Receiving and Decoding ===

At the receiving end (the "Decoder"), a constant stream of samples at the sample frequency must be generated. To do this, the decoder always needs samples "in storage" it can use, if it ever runs out of samples to generate the stream, an "underrun" condition exists, which will cause dropouts and other issues. Consequently, a buffer of samples must be maintained, high enough so that it always is replenished before the D/A runs out of data.

== Delays introduced in the chain ==

As already discussed above, to limit the bandwidth used to a reasonable level, samples must be collected and send as blocks to the destination, via the network.

Audio needs to be sampled into the digital domain at the encoder. In theory, every sample could be directly sent as a block onto the network with minimum delay, but doing this you will create a huge amount of traffic (48.000 blocks per second for 48khz sample rate) and bandwidth requirement (a min. ethernet frame is 60bytes, so you are actually using more than 23MBps if you do this !
So - that is not really a good way of doing this ... the encoder needs to packetize data, send multiple samples in one block. Here is your first source of delay.
Let's assume you want to limit the network load to 100 packets per second, you will need to collect 10ms worth of samples before sending them over the network. With a 48kHz sample frequency, that means 480 samples (960 bytes) for one channel. Makes perfect sense, Ethernet blocks carry up to about 1400 bytes of Data.
Your first sample taken will leave with 10ms delay.
If, instead of PCM, you want to use MP3, the delay will be much more, because (a) MP3 encoding is done on "frames". somewhere between 20ms and 40ms of audio is first sampled, then analyzed and encoded. The encoding process is resource intensive/time consuming, but obviously, it must be average finished within the same time range otherwise you get work to be backed up .. In the MP3 case, expect a "transmit" delay to the network of 2x the frame duration, let's say 60ms.

Now that a block is going to the network, some delay already is introduced (let's stick with the example, 10ms for PCM and 60ms for MP3). The block now needs to be sent over the network, potentially fighting with other traffic for bandwidth. On a local LAN, the delay will typically be quite low (msecs maybe), but beware .. if there is "sometimes" a fight over bandwidth/buffering in a switch or router, you may see average very low delays but PEAK delays could be substantially higher.
Why is that a problem ? Well .. the receiving side always needs to be fed with samples before its buffers run empty .. now, if there is a block delayed, let's say 30ms, the receiver must have buffers configured so that it can live with that delay before running into an error condition (empty buffer). The difference between the min. delay and the max. delay of a network block arriving at the decoder is commonly called "jitter". Jitter can be significant especially with Wifi networks, as there are invisible retries happening in a lower level protocol - you might see (ping command shows all this) an average delay of only 5ms, and zero block loss, but a max. delay of 200ms ... any devce with a receive buffer configured of less than 200ms will mean that you will encur dropouts. period.

Now, let's take a close look at the decoding side. As already stated before, to maintain a constant, consistent stream of samples (which are then converted to an analog value and sent to the audio interface), buffering is a must. The buffers must be able and configured to hold as much data as necessary to cover/survive the longest possible "dry period" when no block comes in from the source, for whatever reason.
If (example above), the source sends a block every 10ms, very precise timing, and zero jitter is introduced by the network (an unlikely scenario), in theory a buffer of one frame is sufficient. When the block arrives from the network, it will be copied into the buffer (let's say, holding 480 samples, in our example with 10ms) and the output can start converting to analog. The buffer now drains, but right when it is getting to "empty", the next block comes in from our perfect encoder through the perfect network infrastructure.
That is, unfortuntately, not a real life scenario, jitter is always introduced somewhere on the way. A realistic setup uses a buffer holding several blocks.
Oh yes, and for MP3, you have to add another reason for delay at the decoder side. Once a frame is received, it cannot be output immediately, but it first needs to be decoded, which is resource intensive and can take several ms ..

The last addition of delay is not really necessary technology wise, but a fact in Barix devices. We use a Main CPU for network tasks and a DSP driving the D/A, which turns the samples back to analog audio. The DSP is necessary for MP3 (and AAC etc etc) decoding, for PCM it mainly works as a pass-through. The interface between the main CPU and the DSP also introduces a buffer at the DSP side, which is counted in bytes, and can introduce quite hefty delays for low bitrate/sample rate streams. Why ? Well, the buffer is counted in Bytes as i said, and let's assume for these examples here it is 2kBytes (2000 bytes), for a PCM 48kHz stream that means 96Bytes per ms, so roughly 20ms - but if you send a 8Khz PCM stream, you get 6x that delay.

So, at the end you have several sources introducing delay, with the buffering for network jitter being often the most significant one, but a "base delay", depending on sample rate, encoding format etc is always present. As you can figure from the above examples, if you have the bandwidth, it often makes sense to configure higher sample rates and bitrate streams, as that will effectively lower the delay due to the fact that the constant (byte wise) buffers in the chain have a smaller through delay.

One last comment, now specific to Barix devices: The Exstreamer 1xx and 2xx decoder devices use a DSP with ample buffering. There is reasons for that, not to be further detailed here. In contrast, the Exstreamer 1000 and the "to be announced monday at NAB" device (hint hint !) as well as all Annuncicom devices use a different DSP with lower buffers, and we are currently beta testing a DSP software patch which reduces the buffers much further to almost non-existing !
With the Exstreamer 1000 and the new device, you can currently achieve delays of below 50ms - the software has not been optimized for very low delay. However, with optimized software, you can get the delay down to well below 20ms - that has been proven in our labs (for a specific project). We are in the process to bring this down further, obviously, this can only be done by sending many more blocks over the network, for example, one per ms - 1000 blocks per second .. ask your Wifi router what it thinks about that ..), so it needs optimized software.

Anyone doing IP codecs is tied by the things explained above - if you can show me a device from any manufacturer, which routes Audio over IP, works over a network with 50ms jitter, sends less than 100 packets per second and introduces an end-to-end delay from input to output of less than 10ms, this manufacturer defied physics and i will be happy to buy you a beer and work for them :)

== Latency measurements ==

Both latencies were measured in the below described test.

=== Test environment ===

The latency was measured with the following equipment:
* Digigiram ES220 as an input device
* another ES220 as a reference output device
* Exstreamer 100 as an output device (VLSI based device)
* Annuncicom 100 as an output device (Micronas based device)
* HP procurve 1700-8 switch where all devices were connected to

Both Barix devices were loaded with the version 00.03 of the Ethersound decoder module.

The input of the ES220 was fed with a 500Hz tone from a signal generator. The input, both output Barix devices as well as the reference ES220 device were monitored with an oscilloscope.

A trigger was set to capture the waveform after switching on the signal generator.

=== Test results ===
The below three diagrams show the results of the measurement. The top line (channel 4, green) is the clock source. Channels 1 (yellow), 2 (blue) and 3 (violet) are: the VLSI device (Exstreamer 100), the Micronas device (Annuncicom 100) and the reference ES220.

'''On the first diagram the 57.2ms latency of the VLSI decoder (Exstreamer 100) can be seen.'''

'''The second screen shot shows the end-to-end latency using a Micronas based device Annuncicom 100. The latency is significantly lower - only 6ms.'''

'''The last picture shows the end-to-end delay using the reference ES220 device. The latency is 1.44ms.'''

IP Audio Delay

2010-04-12T05:10:13Z

Jrietschel: New page: This page discusses the general concept of how Audio over IP works and why there is always an inherent delay/latency in Audio over IP devices - whoever makes them. CURRENTLY WORK IN PROGR...

This page discusses the general concept of how Audio over IP works and why there is always an inherent delay/latency in Audio over IP devices - whoever makes them.

CURRENTLY WORK IN PROGRESS - COME BACK in 2 hours ..

== Latency ==
The end-to-end latency of an Ethersound encoder and a Barix ES100spkr decoder heavily depends on the codec used.

=== VLSI based devices ===
On '''Exstreamer 100, Exstreamer 110 and Exstreamer 200''' the end-to-end latency is approximately '''57ms'''. This is caused by large internal buffers in the VLSI codec.

=== Micronas based devices ===
The internal buffers of the Micronas codec are much smaller which also positively affects the latency.
The end-to-end-latency of the '''Exstreamer 1000, Annuncicom 100, Annuncicom 200 and Annuncicom 1000''' is only about '''6ms'''.

== Latency measurements ==

Both latencies were measured in the below described test.

=== Test environment ===

The latency was measured with the following equipment:
* Digigiram ES220 as an input device
* another ES220 as a reference output device
* Exstreamer 100 as an output device (VLSI based device)
* Annuncicom 100 as an output device (Micronas based device)
* HP procurve 1700-8 switch where all devices were connected to

Both Barix devices were loaded with the version 00.03 of the Ethersound decoder module.

The input of the ES220 was fed with a 500Hz tone from a signal generator. The input, both output Barix devices as well as the reference ES220 device were monitored with an oscilloscope.

A trigger was set to capture the waveform after switching on the signal generator.

=== Test results ===
The below three diagrams show the results of the measurement. The top line (channel 4, green) is the clock source. Channels 1 (yellow), 2 (blue) and 3 (violet) are: the VLSI device (Exstreamer 100), the Micronas device (Annuncicom 100) and the reference ES220.

'''On the first diagram the 57.2ms latency of the VLSI decoder (Exstreamer 100) can be seen.'''

'''The second screen shot shows the end-to-end latency using a Micronas based device Annuncicom 100. The latency is significantly lower - only 6ms.'''

'''The last picture shows the end-to-end delay using the reference ES220 device. The latency is 1.44ms.'''

Main Page

2010-04-12T05:07:17Z

Jrietschel: /* Software Topics */

<big>'''Barix Wiki'''</big>

The Barix Wiki is maintained by Barix staff and users/community. Barix does try to keep the content accurate and error free, and we do review third party contributions, however, we can not guarantee everything is 100% accurate or up-to-date.
If you find any mistakes, errors etc. - please feel free to correct them !

== Barix Newsletter ==

[http://newsletter.barix.com/public/archive.php Click here to read the Barix newsletters.]

== Products ==
=== Audio - Devices and accessories ===
* [[Product Matrix]] - List of HW capabilities versus SW features
* [[Exstreamer 100]] - General Purpose Network Audio Decoder
* [[Exstreamer 110]] - Network Audio Decoder with advanced features - Decodes AAC+
* [[Exstreamer 200]] - Network Audio Decoder with built-in 2x25W class-D amplifier
* [[Exstreamer 1000]] - High Quality Network Audio Encoder/Decoder with symmetric Audio interfaces and AES/EBU
* [[Instreamer 100]] - General Purpose Network Audio Encoder
* [[Annuncicom 100]] - General Purpose Bidirectional Network Audio Device with I/O
* [[Annuncicom 200]] - Network Audio Device suitable for intercom/paging applications with 8W output amplifier and PoE
* [[Annuncicom 1000]] - High End Network Audio Device with balanced audio interfaces and supervised contact closures
* [[Radiobox]] - Radiobox and "Radiobox Pro" - Barix products ?
* [[IPAM 100]]- Embedded IP audio module for OEM with dual network and multiple serial interfaces
* [[IPAM 200 / IPAM 300]]- Embedded IP audio module for OEM (decoder only)
* [[PS16]] - Multifunctional digital desktop paging station PS16
* [[VSC]] - Volume Source Control accessory

=== Automation and Control - Devices and accessories ===
* [[Barionet]] - General Purpose IP Automation Controller with SNMP and Modbus/TCP support, fully programmable. Various I/O capabilities
* [[Barionet 50]] - Low Cost IP Automation Controller with contact closure inputs, relay outputs, serial ports and Dallas Onewire interface
* [[Barionet 200]] - Advanced IP Automation Controller with 16bit analog inputs, analog outputs, RTC and USB flash drive support

* [[Defconlock]] - This is an application specific Barionet, preloaded with an Access Control application (app also separately downloadable)
* [[Barix TS]] - onewire temperature sensors

* [[Barix X8]] - multipurpose RS-485 I/O Interface

* [[Barimon]] - web tool for collecting data from Barix devices: http://www.barimon.net/

== Applications ==
Barix products can be used in a vast variety of applications and markets. Below links bring you to pages which describe applications, which products to use etc
* [[Automation Applications]] - this includes data conversion, collection, remote managment and monitoring (non-audio) applications
* [[Broadcast Applications]] - Applications in the Broadcast Industry such as STL, internet radio, monitoring
* [[General Audio Distribution Applications]] - distribution of audio channels in hotels, over the internet, homes, amusement parks etc
* [[Alarm Applications]] - Use of the Barix products in emergency alerting applications
* [[SIP Applications]] - Use of the Barix products with SIP protocol for SIP speaker, intercom, phone applications
* [[Crestron Integration]] - integrating audio over IP with Crestron touchpanels
* [[IP Intercom]] - a general description and Intercom Applications
* [[Rebroadcasting Application]] - what does it do ?
* [[Messaging / Music on Hold Application from MOH Technology]]

== Hardware Topics ==
* [[Software/Hardware compatibility matrix]]
* [[USB device compatibility list]]
* [[USB and IPAM layout rules]]
* [[Microphones]]

== Software Topics ==

* [[General Topics]]
* [[Protocols used in Barix Products]]
* [[Streaming Client]]
* [[Streaming Client with USB encryption for Digital Rights Management]]
* [[Freeware from Barix]]
* [[BCL Topics]]
* [[Ethersound]]
* [[IP Audio Delay]]

== Support - FAQ & Troubleshooting ==

* [[FAQ]] - general questions, sections about audio and control products

* [[Troubleshooting]]

== Sales & Marketing ==

== Some useful links for using the Wiki ==
Consult the [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.

=== Getting started ===
* [http://www.mediawiki.org/wiki/Manual:Configuration_settings Configuration settings list]
* [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ]
* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]

X8 Register 274

2010-02-26T05:34:40Z

Jrietschel: /* X8 and IO12 register 274 */

=== X8 and IO12 register 274 ===

Register 274 is the serial Interface mode configuration register for both X8 as well as IO12.
The functionality is documented in the X8 manual, however there are some special bits which are not extensively documented in the manual. The following information applies:

* Bit 0: 9600 (set) or 19200 (reset) baud
* Bit 1: reserved
* Bit 2: reserved
* Bit 3: direct I/O (set) or debounced (reset)
* Bit 4: “sticky IO” (set) or standard (reset)
* Bit 5: IO/Change indication (set) or standard Modbus
* Bit 6: Wiegand (set) or standard I/O
* Bit 7: No (set) or even (reset) parity.

Bit 7 and 0 are self-explanatory and also documented in the manual.
For an X8 only (NOT on IO12), setting bit 6 enables "Wiegand" mode. If set, I/O 7 and 6 will serve as a Wiegand interface, and an Access Control reader or keypad can be connected to the X8 on these pins. The X8 will receive wiegand data from the interface and make it available via the modbus interface.

Bit 3: Direct I/O. If set, I/O is not debounced as usual, but directly reported with a register read.

Bit 4: Sticky I/O. If set, any change in the inputs will "freeze" the I/O into a holding register until the data is read from the host (normal poll/read). That allows to catch small pulses. as long as they don't happen more often than a poll cycle. Example: energy meters - their consumption unit output pulse may be only 100ms wide, but won't happen more often than every second (this is an example). Using Sticky I/O, you know you will catch the pulse even if you read multiple X8's in a poll loop and the loop may take half a second.

Bit 5: IO Change indication: this is a special operation mode which is not strictly Modbus/RTU compliant ! It is not recommended to be used unless you know exactly what you are doing.
If a large number of devices (X8, IO12) are connected to a host, you could, for example, use this mode to poll very slowly through the device list. Any device which encounters a change in its I/O will send its Modbus address unsolicited onto the bus if the bus is idle (but this could still mean a collision happens if multiple devices do that at exactly the same time). The Modbus master can recognize the address, or at least that something happened on the bus, and poll the devices. This mode can be combined with Sticky I/O, for example, but again, it is not recommended for general use.

X8 Register 274

2010-02-26T03:49:35Z

Jrietschel: New page: === X8 and IO12 register 274 === Register 274 is the serial Interface mode configuration register for both X8 as well as IO12. The functionality is documented in the X8 manual, however th...

=== X8 and IO12 register 274 ===

Register 274 is the serial Interface mode configuration register for both X8 as well as IO12.
The functionality is documented in the X8 manual, however there are some special bits which are not extensively documented in the manual. The following information applies:

* Bit 0: 9600 (set) or 19200 (reset) baud
* Bit 1: reserved
* Bit 2: reserved
* Bit 3: direct I/O (set) or debounced (reset)
* Bit 4: “sticky IO” (set) or standard (reset)
* Bit 5: IO/Change indication (set) or standard Modbus
* Bit 6: Wiegand (set) or standard I/O
* Bit 7: No (set) or even (reset) parity.

Bit 7 and 0 are self-explanatory and also documented in the manual.
For an X8 only (NO IO12), setting bit 6 enables "Wiegand" mode. If set, bit 7 and 6 will serve as a Wiegand interface, and an Access Control reader or keypad can be connected to the X8 on these pins. The X8 will receive wiegand data from the interface and make it available via the modbus interface.

Bit 3: Direct I/O. If set, I/O is not debounced as usual, but directly reported with a register read.

Bit 4: Sticky I/O. If set, any change in the inputs will "freeze" the I/O into a holding register until the data is read from the host (normal poll/read). That allows to catch small pulses. as long as they don't happen more often than a poll cycle. Example: energy meters - their consumption unit output pulse may be only 100ms wide, but won't happen more often than every second (this is an example). Using Sticky I/O, you know you will catch the pulse even if you read multiple X8's in a poll loop and the loop may take half a second.

Bit 5: IO Change indication: this is a special operation mode which is not strictly Modbus/RTU compliant ! It is not recommended to be used unless you know exactly what you are doing.
If a large number of devices (X8, IO12) are connected to a host, you could, for example, use this mode to poll very slowly through the device list. Any device which encounters a change in its I/O will send its Modbus address unsolicited onto the bus if the bus is idle (but this could still mean a collision happens if multiple devices do that at exactly the same time). The Modbus master can recognize the address, or at least that something happened on the bus, and poll the devices. This mode can be combined with Sticky I/O, for example, but again, it is not recommended for general use.

Barix X8

2010-02-26T03:33:38Z

Jrietschel:

[[Image:X8_FrontAngle_Web800.gif|200px|thumb|right]]
[[Image:X8_Top_Web800.gif|200px|thumb|right]]

The X8 is a universal I/O device, suitable to interface analog, digital signals and specialty sensors such like Dallas Onewire Temperature Sensors ([[Barix TS]]) or Access Control readers with wiegand interface to an RS485 bus.
The bus protocol is Modbus/RTU.

Barix Modbus I/O device family is a low-cost, high reliability range of interfaces between Modbus capable hosts and sensors/actors. All products talk Modbus/RTU as the standard protocol, and are configurable via standard Modus read/write commands.

With the Barionet, a smart ethernet controller which is fully programmable and can also translate between Modbus/TCP and SNMP, the Barix Modbus I/O devices can be interfaced to about any host system. Standard SNMP or Modbus/TCP OPC servers can directly talk to the Barix I/O device family.

While the R6 (6 relays, 10/16Amps at 250V) and IO12 (12 high current sourcing outputs, 12 opto isolated inputs) are typical standard components, the unique X8 provides a feature set ideal for modern building management and security applications, yet supporting the standard Modbus/RTU protocol. Its 8 I/O terminals can be individually configured to work as analog inputs (0--5V, 10bit resolution), as contact closure detection inputs, as TTL level digital inputs, as TTL level digital outputs (suitable to drive LED's). However, three special capabilities are unique in this device class:

* The X8 directly interfaces Wiegand capable access control readers or keypads to Modbus!
* The X8 directly interfaces Dallas Onewire temperature sensors to Modbus!
* The X8 directly interfaces Sensirion SHT sensors for high precision temperature and humidity reading
to Modbus!

All these functions can be configured in the X8 via the Modbus/RTU interface using standard register writes. Special functions (interfacing of rotary encoders, custom protocols etc) can be implemented on request. As the X8 is software upgradeable, new functions can be uploaded in the unit even after installation in the field.

Please contact Barix if you need a special interface for any type of I/O to Modbus or Modbus/TCP. With our extensive experience in the Modbus protocol and interfacing market, we will be pleased to offer you a custom solution.

=== X8 Firmware Update procedure ===
Here is a page describing the update procedure - how to update the firmware of an X8 over the RS-485 port:[[X8-Update]]

=== How to wire Barix TS to the X8 ===
The X8 supports up to 8 temperature sensors, one per input. The sensors are autodetected, no need to configure these.
However, the corresponding I/O bits must be configured as INPUTS for the sensors to be detected.
If you only need the X8 for a couple of I/O and one temperature sensor (as it would typically be the case in a light switch), you can wire the temperature sensor to input pins and program the I/O connected to the "ground" wire of the temperature sensor as output with value 0. Example:

If a Barix TS is connected between I/O 7 (ground wire) and I/O 8 (data wire), I/O 7 needs to be programmed as output and default 0.
Of course, if the Barix TS is connected between any I/O pin and ground, no programming is required.

=== X8 special firmware modes ===
The X8 and IO12 know some special tricks to make recognition of connected I/O easier. These special I/O modes can be configured in register 274 (serial interface mode). Please see here: [[X8 Register 274]]

In addition, special operation modes (NOT Modbus compatible) can be enabled for aplications like rotary encoder, Annuncicom table selector, or a generic "no polling" mode where the analog values of all 8 inputs are simply sent as a hex string to the serial port (on change or in regular interval). Please contact Barix for details.

Back to [[Main Page#Products]]

On the fly IP Address change

2009-12-20T14:13:58Z

Jrietschel: New page: This wiki page describes a function common to all Barix IP devices, and a potential issue with routers "breaking the rules": A Barix IP device has a built-in way of reconfiguring the IP a...

This wiki page describes a function common to all Barix IP devices, and a potential issue with routers "breaking the rules":

A Barix IP device has a built-in way of reconfiguring the IP address temporarily. This functionality is documented well and very useful. Under normal circumstances, this is considered "safe" as, to use the function, it is necesssary to know the MAC address of the device AND to be on the local network.

The functionality is called the "ARP Trick", and it allows the setup of a Barix device which has an unknown, probably "wrong" configuration on the network. So, how does it work ?

To switch the IP address to a known one temporarily, two steps are required.
First, on a local PC, you need to set up a static ARP entry (the ARP protocol is normally used to associate the IP Address of the device with the MAC address actually used to address the unit on the Ethernet).
In setting up such a static ARP entry, you give the workstation/PC you use the information on how to send IP blocks to the device. In normal circumstances, that information is detected by the ARP protocol, but if a device has an unknown configuration/non-local IP address, it of course will not answer to the search request sent out by the ARP protocol handler - which is the normal case.
Again, to generate such an ARP entry, you need to provide both the IP address you want to assign as well as the MAC address to the arp protocol handler of your PC/workstation. That is typically done with the command (example, of course, IP address and MAC must be replaced with your real values)

arp -s 192.168.1.12 00-08-E1-12-34-56

You can then verify that a static entry has been created in the ARP table with the "arp -s" command. On mac/linux systems, you need to use a colon ":" instead of the dash "-" in the MAC address.

Once this entry is established, the PC/workstation now knows how to send traffic to that IP address, and if you now ping the IP or use the browser, the IP frames will be sent to the MAC address given ... however, Barix devices will still ignore these blocks because they are NOT carrying the right IP address.

Now comes the trick: if you send a TCP connection establishment request to port 1, however, the device understands this as a very special command and "switches" the IP Address to the destination IP of the block, and resets the netmask to the default netmask for that IP address.

So, after you have done a TCP connect try using port number 1 (can be done with a browser by specifying port 1 as part of the URL, or by telnet, or any other application using TCP with a configurable port number), the device will be switched to that IP address and of course "lose" the old IP address, until it is rebooted.

The described method is considered "safe" for the following reasons:

a) it only works on a local network, and only if you know the MAC address of the device
b) if you know an IP and MAC of a device and have access to the low level protocol functionality on a workstation, you can disturb communications for that device by many means - creating fake ARP entries is just one method.
c) because the ARP layer on devices like routers and gateways is generally not available, there seems to be no way how to do this "remote"

... well, you think so.

It has been reported now in one case (Alan) that a router (exact make and version should be added here) behaves wrongly and causes problems. What happens ?

On the internet, there are many culprits running port scanner software to find PCs to infect. These port scanners typically "scan" all IP addresses by trying to establish a TCP connection to every possible port (of course, scanning 2^32 IP addresses with 64k ports each takes quite a while, but the tools are smart and only look in certain IP address ranges).

So, what happens if a port scanner hits port 1 ? And it is forwarded by the router (which should NOT be the case, you should generally filter all ports other than the ones needed !!)

If the port scanner hits the IP of the Barix device and the port 1 TCP connection request is forwarded, it will be refused, BUT the Barix device will reset its netmask. So far so good, that will not have a disturbing effect in most cases as traffic over the internet generally uses non-local addresses, so the gateway will still be used.
HOWEVER: what seems to happen in the customer case is much worse. The port scanner increments IP addresses and also tries the "broadcast" address of the network. A TCP connection request to the broadcast address makes absolutely NO sense, and the router must NOT forward it.
BUT .. apparently, it does so - even using the Ethernet broadcast address ! Clear violation of about any rule.
Our devices receive the TCP connection request to port one because they are sent using the broadcast address .. and they assume that address temporarily.
Now the device is not any more reachable on the configured address, but on another address. A magic "IP address change" happened.

How can this be prevented:

well, quite simple:

a) update the router with fixed firmware (if it exists) or use a router which does comply with the standards and does NOT forward/send out TCP requests to the broadcast address via broadcast on the network
b) configure the router to block traffic at least to port 1, better to all ports and selectively only open the ports needed.
c) you can also ask your ISP why they forward traffic to the local broadcast address from the Internet, that is questionable as well .. if they give you a subnet/IP address range, they should know what your local "network" and "broadcast" addresses are and not send traffic to them.

We at Barix will modify the functionality of our stack, trying to prevent such issues.
First measure is to check for this specific case if the block is arriving by broadcast hardware address and ignoring it in that case.
Second measure will be likely to time-limit the functionality to 60 seconds after reboot/restart - so it will be only possible to reset the IP address using the ARP trick within the first minute after erset/power up of the device. But we need to discuss this and all the implications first before we an go ahead and implement it.

20.12.09 JR

Troubleshooting

2009-12-20T13:27:52Z

Jrietschel:

*[[USB_device_compatibility_list|Trouble with USB sticks]]
*[[How to get the IP Address]]
*[[RS485 Termination]]
*[[WLAN Broadcast/Multicast]] - Problems using Broadcast over 802.11 WLAN infrastructure
*[[On the fly IP Address change]]

Back to [[Main Page#Support - FAQ & Troubleshooting]]

Radiobox

2009-11-17T09:51:34Z

Jrietschel:

'''Radiobox''' and '''Radiobox Pro'''

In France, the company Broadcast Associes offers an Instreamer-Exstreamer solution under the name "Radiobox". The encoder and decoder are standard Barix devices with original Barix firmware, however, Broadcast Associes has modified the HTML pages to be bi-langue (english/french) and did some changes to the configuration options (hidden some fields, renamed others) to improve the useability for Broadcasters. Broadcast Associes supports customers in the installation of the solution.

At IBC2008, Barix invited Broadcast Associes to the Barix booth, because they planned to use the Exstreamer 1000 PCB as the basis for a new product, "Radiobox Pro". A prototype has been shown at IBC 2008 at the Barix booth and Broadcast Associes were present at the Barix booth, being introduced to prospects and customers of Barix stopping at the booth. Subsequently, Barix did a press release with Broadcast Associes about the "Radiobox Pro" product, which Broadcast Associes told Barix will be finished after a couple of months/available in 2009.

The Exstreamer 1000, Barix' broadcast "pro" model, is designed using a space saving 1/2 width 19' case, which can easily be rack mounted. The Broadcast Associes Radiobox Pro approach was planned to take the PCB of the Exstreamer 1000, mounting it in a full size 19' box, adding a compact flash reader (interfacing to the Exstreamer 1000's USB port), an internal power supply, and XLR connectors instead of the standard space-saving DB9 connectors used by Barix. Other than that, the Radiobox Pro device at that time was based on the standard Barix Exstreamer 1000 with a modified UI and eventually custom written application (and a significantly higher price).

Unfortunately, the Radiobox Pro device never made it to the market. Barix still gets enquiries from the press releases done in 2008 for the product - fortunately, the Exstreamer 1000 is shipping and well received in the market for STL, brodcast and pro audio solutions. A special "STL" software for the Exstreamer 1000, designed to cover all requirements a Broadcaster may have, is available pre-loaded through the Barix distribution.

The existing Radiobox products are available from Braodcast Associes in France, and of course, the standard Barix products suitable for Broadcast applications, such as the Exstreamer 1000, Exstreamer 100 and Instreamer 100 can be ordered through the Barix Distributor Sphinx France.

Radiobox

2009-11-17T09:51:04Z

Jrietschel:

'''Radiobox''' and '''Radiobox Pro'''

In France, the company Broadcast Associes offers an Instreamer-Exstreamer solution under the name "Radiobox". The encoder and decoder are standard Barix devices with original Barix firmware, however, Broadcast Associes has modified the HTML pages to be bi-langue (english/french) and did some changes to the configuration options (hidden some fields, renamed others) to improve the useability for Broadcasters. Broadcast Associes supports customers in the installation of the solution.

At IBC2008, Barix invited Broadcast Associes to the Barix booth, because they planned to use the Exstreamer 1000 PCB as the basis for a new product, "Radiobox Pro". A prototype has been shown at IBC 2008 at the Barix booth and Broadcast Associes were present at the Barix booth, being introduced to prospects and customers of Barix stopping at the booth. Subsequently, Barix did a press release with Broadcast Associes about the "Radiobox Pro" product, which Broadcast Associes told Barix will be finished after a couple of months/available in 2009.

The Exstreamer 1000, Barix' broadcast "pro" model, is designed using a space saving 1/2 width 19'' case, which can easily be rack mounted. The Broadcast Associes Radiobox Pro approach was planned to take the PCB of the Exstreamer 1000, mounting it in a full size 19'' box, adding a compact flash reader (interfacing to the Exstreamer 1000's USB port), an internal power supply, and XLR connectors instead of the standard space-saving DB9 connectors used by Barix. Other than that, the Radiobox Pro device at that time was based on the standard Barix Exstreamer 1000 with a modified UI and eventually custom written application (and a significantly higher price).

Unfortunately, the Radiobox Pro device never made it to the market. Barix still gets enquiries from the press releases done in 2008 for the product - fortunately, the Exstreamer 1000 is shipping and well received in the market for STL, brodcast and pro audio solutions. A special "STL" software for the Exstreamer 1000, designed to cover all requirements a Broadcaster may have, is available pre-loaded through the Barix distribution.

The existing Radiobox products are available from Braodcast Associes in France, and of course, the standard Barix products suitable for Broadcast applications, such as the Exstreamer 1000, Exstreamer 100 and Instreamer 100 can be ordered through the Barix Distributor Sphinx France.

Radiobox

2009-11-10T21:05:32Z

Jrietschel:

'''Radiobox''' and '''Radiobox Pro'''

In France, the company Broadcast Associes offers an Instreamer-Exstreamer solution under the name "Radiobox". The encoder and decoder are standard Barix devices with standard Barix firmware, however, Broadcast Associes has modified the HTML pages to be bi-langue (english/french) and did some changes to the configuration options (hidden some fields, renamed others). With a Radiobox "solution", which consists of one Instreamer and one Exstreamer, loaded with the modified UI, a USB stick is bundled and the package is offered at a higher price than the Barix suggested list price. Broadcast Associes supports customers in the installation of the solution.

At IBC2008, Barix invited Broadcast Associes to the Barix booth, because they claimed they will use the Exstreamer 1000 PCB as the basis for a new product, "Radiobox Pro". A prototype has been shown at IBC 2008 at the Barix booth and Broadcast Associes were present at the Barix booth, being introduced to prospects and customers of Barix stopping at the booth. Subsequently, Barix did a press release with Broadcast Associes about the "Radiobox Pro" product, which Broadcast Associes told Barix will be finished after a couple of months/available in 2009.

The Exstreamer 1000, Barix' broadcast "pro" model, is designed using a space saving 1/2 width 19'' case, which can easily be rack mounted. The Broadcast Associes Radiobox Pro approach was planned to take the PCB of the Exstreamer 1000, mounting it in a full size 19'' box, adding a compact flash reader (interfacing to the Exstreamer 1000's USB port), an internal power supply, and XLR connectors instead of the standard space-saving DB9 connectors used by Barix. Other than that, the Radiobox Pro device at that time was based on the standard Barix Exstreamer 1000 with a modified UI and eventually custom written application (and a significantly higher price).

Unfortunately, the Radiobox Pro device never made it to the market. Barix still gets enquiries from the press releases done in 2008 for the product - fortunately, the Exstreamer 1000 is shipping and well received in the market for STL, brodcast and pro audio solutions. A special "STL" software for the Exstreamer 1000, designed to cover all requirements a Broadcaster may have, is available pre-loaded through the Barix distribution.

The existing Radiobox products from Braodcast Associes (which are in fact re-branded Barix standard products with standard firmware and a customized UI) continue to be available from Broadcast Associes in France, and of course, the standard Barix products suitable for Broadcast applications, such as the Exstreamer 1000, Exstreamer 100 and Instreamer 100 can be ordered through the Barix Distributor Sphinx France.

Barix sincerely apologizes to all customers, prospects and broadcasters for releasing a press statement about an OEM product (Radiobox Pro) which turned out to not be available. We will be more careful in the future about doing press releases with partners who announce solutions and do not have them ready for shipping.

Radiobox

2009-11-03T18:56:06Z

Jrietschel:

'''Radiobox''' and '''Radiobox Pro'''

In France, the company Broadcast Associes takes Exstreamer-100 and Instreamer-100 products and resells these under the name "Radiobox". These are standard Barix products, branded with the "Radiobox" name by Broadcast Associes.

At IBC2008, Barix invited Broadcast Associes to the Barix booth, because they claimed they will use the Exstreamer 1000 PCB as the basis for a new product, "Radiobox Pro". A prototype has been shown at IBC 2008 at the Barix booth and Broadcast Associes was at the Barix booth, being introduced to prospects. Subsequently, Barix did a press release with Broadcast Associes about the "Radiobox Pro" product, which Broadcast Associes told Barix will be finished after a couple of months.

The Exstreamer 1000, Barix' broadcast "pro" model, is designed using a space saving 1/2 width 19'' case, which can easily be rack mounted. The Broadcast Associes Radiobox Pro approach was taking the PCB of the Exstreamer 1000, mounting it in a full size 19'' box, adding a compact flash reader (interfacing to the Exstreamer 1000's USB port), an internal power supply, and XLR connectors instead of the standard space-saving DB9 connectors used by Barix. Other than that, the Radiobox Pro device was based on the standard Barix Exstreamer 1000 with a modified UI (and a significantly higher price).

Unfortunately, the Radiobox Pro device never made it to the market. Barix still gets enquiries from the press releases done in 2008 for the product - fortunately, the Exstreamer 1000 is shipping and well received in the market for STL, brodcast and pro audio solutions.

Radiobox (=Barix re-branded Barix standard products) continue to be available by Broadcast Associes in France, and of course, the standard Barix Exstreamer 100 and Instreamer 100 devices can also be ordered through the Barix Distributor Sphinx France.

Barix will be more careful in the future in doing press releases about non-finished OEM products like Broadcast Associe's Radiobox Pro.

Microphones

2009-11-02T05:04:37Z

Jrietschel: New page: '''This page informs about Microphones which can be used with Barix Annuncicom products.''' The Annuncicom Microphone input is suitable for typical electret microphones, but other types w...

'''This page informs about Microphones which can be used with Barix Annuncicom products.'''

The Annuncicom Microphone input is suitable for typical electret microphones, but other types work as well (dynamic microphones).

The input impedance depends on the configuration of the input gain, min. 8KOhm (at +43.5dB amp level), max. 94kOhm at +21dB.
The input will clip at round 280mV.
A third connection pin (on both 3.5mm connector as well as on the contact block) provides a "bias" voltage source of about 2.5V, perfectly suiting most electret microphones. If a microphone needs 12V, the voltage can typically also be taken from the Annuncicom power supply, provided it is a 12V regulated type.

Please make sure that if you use an electret microphone, the source voltage is also connected. A microphone not powered by the Annuncicom must be connected to pins 1 and 3 of the contact block, pin 2 provides the source voltage. The output impedance of the mic bias source is 5kOhm.

Customers report back that for security type applications, the pinhole microphone EK-23024 from Knowles works really well:
[http://www.knowles.com/search/family.do?family_id=EK/EY&x_sub_cat_id=8]

Main Page

2009-11-02T04:58:37Z

Jrietschel: /* Hardware Topics */

<big>'''Barix Wiki'''</big>

The Barix Wiki is maintained by Barix staff and users/community. Barix does try to keep the content accurate and error free, and we do review third party contributions, however, we can not guarantee everything is 100% accurate or up-to-date.
If you find any mistakes, errors etc. - please feel free to correct them !

== Products ==
=== Audio - Devices and accessories ===
* [[Product Matrix]] - List of HW capabilities versus SW features
* [[Exstreamer 100]] - General Purpose Network Audio Decoder
* [[Exstreamer 110]] - Network Audio Decoder with advanced features - Decodes AAC+
* [[Exstreamer 200]] - Network Audio Decoder with built-in 2x25W class-D amplifier
* [[Exstreamer 1000]] - High Quality Network Audio Encoder/Decoder with symmetric Audio interfaces and AES/EBU
* [[Instreamer 100]] - General Purpose Network Audio Encoder
* [[Annuncicom 100]] - General Purpose Bidirectional Network Audio Device with I/O
* [[Annuncicom 200]] - Network Audio Device suitable for intercom/paging applications with 8W output amplifier and PoE
* [[Annuncicom 1000]] - High End Network Audio Device with balanced audio interfaces and supervised contact closures
* [[Radiobox]] - Radiobox and "Radiobox Pro" - Barix products ?
* [[IPAM 100]]- Embedded IP audio module for OEM with dual network and multiple serial interfaces
* [[IPAM 200 / IPAM 300]]- Embedded IP audio module for OEM (decoder only)
* [[PS16]] - Multifunctional digital desktop paging station PS16
* [[VSC]] - Volume Source Control accessory

=== Automation and Control - Devices and accessories ===
* [[Barionet]] - General Purpose IP Automation Controller with SNMP and Modbus/TCP support, fully programmable. Various I/O capabilities
* [[Barionet 50]] - Low Cost IP Automation Controller with contact closure inputs, relay outputs, serial ports and Dallas Onewire interface
* [[Barionet 200]] - Advanced IP Automation Controller with 16bit analog inputs, analog outputs, RTC and USB flash drive support

* [[Defconlock]] - This is an application specific Barionet, preloaded with an Access Control application (app also separately downloadable)
* [[Barix TS]] - onewire temperature sensors

* [[Barix X8]] - multipurpose RS-485 I/O Interface

* [[Barimon]] - web tool for collecting data from Barix devices: http://www.barimon.net/

== Applications ==
Barix products can be used in a vast variety of applications and markets. Below links bring you to pages which describe applications, which products to use etc
* [[Automation Applications]] - this includes data conversion, collection, remote managment and monitoring (non-audio) applications
* [[Broadcast Applications]] - Applications in the Broadcast Industry such as STL, internet radio, monitoring
* [[General Audio Distribution Applications]] - distribution of audio channels in hotels, over the internet, homes, amusement parks etc
* [[Alarm Applications]] - Use of the Barix products in emergency alerting applications
* [[SIP Applications]] - Use of the Barix products with SIP protocol for SIP speaker, intercom, phone applications
* [[Crestron Integration]] - integrating audio over IP with Crestron touchpanels
* [[IP Intercom]] - a general description and Intercom Applications
* [[Rebroadcasting Application]] - what does it do ?

== Hardware Topics ==
* [[Software/Hardware compatibility matrix]]
* [[USB device compatibility list]]
* [[USB and IPAM layout rules]]
* [[Microphones]]

== Software Topics ==

* [[General Topics]]
* [[Protocols used in Barix Products]]
* [[Streaming Client]]
* [[Streaming Client with USB encryption for Digital Rights Management]]
* [[Freeware from Barix]]
* [[BCL Topics]]
* [[Ethersound]]

== Support - FAQ & Troubleshooting ==

* [[FAQ]] - general questions, sections about audio and control products

* [[Troubleshooting]]

== Sales & Marketing ==

== Some useful links for using the Wiki ==
Consult the [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.

=== Getting started ===
* [http://www.mediawiki.org/wiki/Manual:Configuration_settings Configuration settings list]
* [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ]
* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]

Ethersound

2009-10-23T00:36:57Z

Jrietschel:

== Ethersound on Barix products ==
Since early 2009, most Barix Audio products come with firmware or allow installation of firmware which provides ETHERSOUND functionality. Specifically, all products capable of decoding (Exstreamer and Annuncicom product series) can be used in Ethersound installations.

== Supported Ethersound version ==
Barix implemented Ethersound support in software (compared with most other manufacturers, who use a chip based approach). Most Barix products do not have dual Ethernet functionality.
For the ES100 (Ethersound 100) full support, a device needs to be able to be daisy chained AND must insert only minimal delay and latency in the Ethersound device chain.

Barix worked with Digigram to define a relaxed timing/functionality Substandard, which has been named ES100/Spkr. ES100/Spkr devices are fully interoperable with other ES100 devices, fully manageable by Ethersound management software, but only provide output capability and can only be connected "downstream" of the sources, using switches. No daisychain is supported. Typically, ES100/Spkr are ideally suited to distribute Ethersound to larger areas where speakers need to be installed, for example, in churches, concert halls, stadiums etc.

== Functionality of the Barix Ethersound firmware ==
Barix has implemented ES100/Spkr in software, and the firmware module is bundled and loaded in most standard products. On the configuration web page, a button "Ethersound" is available to switch the devices into Ethersound mode. For "stereo" capable devices, two different Ethersound channels can be independently selected for the left and right output. The functionality is, otherwise, rather simple - channels can be dynamically selected/changed while the device operates (via management/control software as well as via IR or a volume source control), and I/O on the devices is also manageable from central software. Obviously, once the device is configured to Ethersound mode, it won't speak IP any more (Ethersound needs a dedicated 100MBit network), but the device can, at any time, be reconfigured for IP use by means of either a factory defaults reset or by starting the device in update mode.

== Licensing/Cost ==
All Barix Exstreamer and Annuncicom devices are fully licensed as ES100/Spkr devices and can be used by the customer without any further cost/license requirement. Note that although the functionality can also be used on all IPAM modules and Barix can provide these with the ES100/Spkr license as well, any OEM who wants to use Ethersound with Barix IPAM devices will need to register his own Vendor ID with Digigram and notify Barix about his intensions so that the Barix can pay the royalties accordingly.

== Latency ==

There is a separate wiki page discussing the latency of the Barix ES100/Spkr implementation: [[Ethersound latency]]

Ethersound

2009-10-23T00:20:08Z

Jrietschel:

* [[Ethersound on Barix products]]

* [[supported Ethersound version]]

* [[functionality of the Barix Ethersound firmware]]

* [[NO additional licensing]]

* [[Ethersound latency]] - on Annuncicom and Exstreamer-1000 products approx. 6ms, on all other Exstreamer products about 56ms

Ethersound

2009-10-23T00:18:42Z

Jrietschel:

* [[Ethersound on Barix products]]

* [[supported Ethersound version]]

* [[functionality of the Barix Ethersound firmware]]

* [[NO additional licensing]]

* [[Ethersound latency]]

Radiobox

2009-10-23T00:14:30Z

Jrietschel: New page: '''Radiobox''' and '''Radiobox Pro''' In France, the company Broadcast Associes takes Exstreamer-100 and Instreamer-100 products and resells these under the name "Radiobox". These are the...

'''Radiobox''' and '''Radiobox Pro'''

In France, the company Broadcast Associes takes Exstreamer-100 and Instreamer-100 products and resells these under the name "Radiobox". These are the 100% same products as the originals, with the exception of a Sticker on them ... of course, if you call Broadcast Associes, they will not say so.

At IBC2008, Barix invited Broadcast Associes to the Barix booth, because they claimed they will use the Exstreamer 1000 PCB as the basis for a new product, "Radiobox Pro". They even showed a prototype and Barix was dumb enough to share the visitors with them and do a press release about the "Radiobox Pro" product, which Broadcast Associes promised to finish. The Exstreamer 1000, Barix' broadcast "flagship", is designed using a space saving 1/2 width 19'' case, which can easily be rack mounted. Broadcast Associes claims that broadcast customers can not live with a product which uses DB9 connectors and not space hungry XLR connectors for an STL and generic broadcast product - and that there must be a Compact Flash and not a USB memory for backup. That's the difference of the alledged "Radiobox Pro", besides the price (about 70% more of what Barix charges for the Exstreamer 1000.

Well, seems there has not been much interest by customers for an overpriced Exstreamer-1000 with XLR connectors, so Broadcast Associes has decided to NOT build the Radiobox Pro as originally planned and showcased at IBC2008. It will be interesting to see if Sylvain Cavet and Fabrice Gauthier, the founders of Broadcast Associes, can continue with their strategy of using well priced Barix (and maybe other) products, obscuring the make of the products, and selling them at higher prices as "their" invention.

And it will be interesting if Barix will run in such a trap again and believe wanna-be OEMs, providing marketing help with a well known brand for Vaporware ...

Radiobox Pro, definitely, is Broadcast-associes vaporware. The Exstreamer 1000 is providing the same functionality and is shipping, making Broadcasters happy around the world.

Main Page

2009-10-23T00:02:10Z

Jrietschel: /* Audio - Devices and accessories */

<big>'''Barix Wiki'''</big>

The Barix Wiki is maintained by Barix staff and users/community. Barix does try to keep the content accurate and error free, and we do review third party contributions, however, we can not guarantee everything is 100% accurate or up-to-date.
If you find any mistakes, errors etc. - please feel free to correct them !

== Products ==
=== Audio - Devices and accessories ===
* [[Product Matrix]] - List of HW capabilities versus SW features
* [[Exstreamer 100]] - General Purpose Network Audio Decoder
* [[Exstreamer 110]] - Network Audio Decoder with advanced features - Decodes AAC+
* [[Exstreamer 200]] - Network Audio Decoder with built-in 2x25W class-D amplifier
* [[Exstreamer 1000]] - High Quality Network Audio Encoder/Decoder with symmetric Audio interfaces and AES/EBU
* [[Instreamer 100]] - General Purpose Network Audio Encoder
* [[Annuncicom 100]] - General Purpose Bidirectional Network Audio Device with I/O
* [[Annuncicom 200]] - Network Audio Device suitable for intercom/paging applications with 8W output amplifier and PoE
* [[Annuncicom 1000]] - High End Network Audio Device with balanced audio interfaces and supervised contact closures
* [[Radiobox]] - Radiobox and "Radiobox Pro" - Barix products ?
* [[IPAM 100]]- Embedded IP audio module for OEM with dual network and multiple serial interfaces
* [[IPAM 200 / IPAM 300]]- Embedded IP audio module for OEM (decoder only)
* [[PS16]] - Multifunctional digital desktop paging station PS16
* [[VSC]] - Volume Source Control accessory

=== Automation and Control - Devices and accessories ===
* [[Barionet]] - General Purpose IP Automation Controller with SNMP and Modbus/TCP support, fully programmable. Various I/O capabilities
* [[Barionet 50]] - Low Cost IP Automation Controller with contact closure inputs, relay outputs, serial ports and Dallas Onewire interface
* [[Barionet 200]] - Advanced IP Automation Controller with 16bit analog inputs, analog outputs, RTC and USB flash drive support

* [[Defconlock]] - This is an application specific Barionet, preloaded with an Access Control application (app also separately downloadable)
* [[Barix TS]] - onewire temperature sensors

* [[Barix X8]] - multipurpose RS-485 I/O Interface

* [[Barimon]] - web tool for collecting data from Barix devices: http://www.barimon.net/

== Applications ==
Barix products can be used in a vast variety of applications and markets. Below links bring you to pages which describe applications, which products to use etc
* [[Automation Applications]] - this includes data conversion, collection, remote managment and monitoring (non-audio) applications
* [[Broadcast Applications]] - Applications in the Broadcast Industry such as STL, internet radio, monitoring
* [[General Audio Distribution Applications]] - distribution of audio channels in hotels, over the internet, homes, amusement parks etc
* [[Alarm Applications]] - Use of the Barix products in emergency alerting applications
* [[SIP Applications]] - Use of the Barix products with SIP protocol for SIP speaker, intercom, phone applications
* [[Crestron Integration]] - integrating audio over IP with Crestron touchpanels
* [[IP Intercom]] - a general description and Intercom Applications
* [[Rebroadcasting Application]] - what does it do ?

== Hardware Topics ==
* [[Software/Hardware compatibility matrix]]
* [[USB device compatibility list]]
* [[USB and IPAM layout rules]]

== Software Topics ==

* [[General Topics]]
* [[Protocols used in Barix Products]]
* [[Streaming Client]]
* [[Streaming Client with USB encryption for Digital Rights Management]]
* [[Freeware from Barix]]
* [[BCL Topics]]
* [[Ethersound]]

== Support - FAQ & Troubleshooting ==

* [[FAQ]] - general questions, sections about audio and control products

* [[Troubleshooting]]

== Sales & Marketing ==

== Some useful links for using the Wiki ==
Consult the [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.

=== Getting started ===
* [http://www.mediawiki.org/wiki/Manual:Configuration_settings Configuration settings list]
* [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ]
* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]

Barionet RTC

2009-04-20T01:11:55Z

Jrietschel: New page: == Barionet RTC == You can build your own ... or you can order it (special order, quantities apply). If you want to build your own, here's how. * get the DS1904, it is a Dallas Onewire ...

== Barionet RTC ==

You can build your own ... or you can order it (special order, quantities apply).

If you want to build your own, here's how.

* get the DS1904, it is a Dallas Onewire "Button", a realtime clock device with integrated battery
* either connect it outside to the Barionet (standard onewire connection to J5, see the comments in the manual !
* or add inside the case:
** you need to open the case
** you need to locate connector "J1", which is a 4 pin jumper header.
*** connect the "signal" of the RTC to pin 2 of J1 (which is the onewire interface, so you can measure 0Ohm resistance between this pin and the external onewire pin on J5)
*** connect the "ground" of the RTC to pin 4 of J1 (which is logic ground, same as pin 14 of J6)

The standard firmware automatically detects and supports the RTC.

Barionet

2009-04-20T01:05:06Z

Jrietschel:

[[Image:Barionet_Web400.png|200px|thumb|right]]

.. to be described.

Here is a link to the description of the new version of the ASCII control protocol: [[Barionet TCP Protocol v2]]

Barionet with Realtime Clock ? Yes, that is possible !

We have the "Barionet RTC" on special order/request, and you can also "build your own": [[Barionet RTC]]

Back to [[Main Page#Products]]

Barimon FAQ

2009-03-14T21:18:32Z

Jrietschel: New page: - to be filled -

- to be filled -

Barimon

2009-03-14T21:18:18Z

Jrietschel: New page: Barimon - monitoring website and service to record data from remote devices Check the Barimon FAQ

Barimon - monitoring website and service to record data from remote devices

Check the [[Barimon FAQ]]

Connecting to 3G Networks

2009-01-29T08:39:20Z

Jrietschel: New page: Barix Devices only have an Ethernet connection. Quite often, customers want to use them in mobile applications, in places where there is no ADSL, probably not even a telephone line. Vario...

Barix Devices only have an Ethernet connection. Quite often, customers want to use them in mobile applications, in places where there is no ADSL, probably not even a telephone line.

Various wireless access technologies have been developed and are used in most locations now, being it EDGE, UMTS, 3G EVDO, CDMA, Wimax or even satellite based connectivity solutions.

All the above connectivity methods allow you to connect to an intranet or the internet. Barix devices are generally work well with all these connectivity methods because they are strictly based on standards- TCP/IP. Of course, the connection speed may be a limiting factor - a satellite connection with 9600 baud cannot be used for audio streaming.

For all and every such connectivity solution "access routers" or bridges do exist which provide an ethernet connection. In many cases, a generic router/bridge, such as the Level One WBR-3800 3G Wireless Router [http://global.level1.com/product_d.php?id=515], plus a USB or PCMCIA card, typically provided by the carrier, are required. Barix does not endorse or recommends a specific brand or maker, but we have tested and used the mentioned Level One product and it is affordable (from around 100€ in Europe), working really well, and gives broadband speeds with HSPDA, Ethernet and wireless connectivity (so you can share the broadband connection between Barix devices and notebooks, for example). Other manufacturers which make similar products include Multitech and Linksys.

Depending on the contract with the wireless connectivity provider, you may or may not get a static IP address, bandwidth may be charged for on a per kByte basis or flat fee, you may be able to get a VPN, some functionality may or may not be blocked or forbidden - you need to figure this out yourself.

FAQ

2009-01-29T08:23:56Z

Jrietschel: /* General questions - IP, Addressing, Multicast etc */

== FAQ ==

This is a list of common questions and answers, for most of the answers a detailed description is linked

'''

== General questions - IP, Addressing, Multicast etc ==

* '''What is SonicIP?'''
SonicIP is a feature of all Barix audio devices which at the start-up announces the device's IP address to the attached headphones/speakers. This is useful for the technician in the installation phase before the device gets a fixed IP address; e.g. when it is attached to a DHCP network for the first time after unpacking. Typically after the device is configured the SonicIP is switched off not to disturb the listeners in the operational environment if the device is eventually reset.

* '''What is AutoIP, IPzator, etc.and how do I use them?'''
These are methods to automatically obtain an IP address if the device is not configured to a fixed address. Read more in this [[AutoIP Howto]]

* '''Do the Barix products support Multicast and IGMP ?'''
Yes, the Barix products do fully support Multicast and IGMP. However, depending on the firmware and application used, there maybe are some caveats. Read more here: [[Multicast]]

* '''Do the Barix products support IPv6 ?'''
No, at the current time, no IPv6 support is implemented in the Barix products

* '''I want to set up a local network with more than 250 devices, what do i have to do ?'''
No Problem - but you will not be able to use a "class C" address (192.168....). A "private" range well useable for larger networks is 172.16.x.x, with the default netmask 255.255.0.0. This gives you roughly 65000 possible hosts ... should be sufficient ?

* '''I want to do a broadcast over different subnets, is that possible ?'''
A broadcast is a local function, read here: [[broadcast]]. Broadcasts can not be sent over different subnets. However, you may be able to use [[Multicast]]. Barix devices can also provide "rebroadcasting" functionality, which means that a device in a remote network receives a stream and sends it back out to the local network as broadcast or multicast. Using that functionality, a broadcast can be sent to a remote network.

* '''How do the devices get their IP address ?'''
When you plug the power supply into the power jack of the device and the other end into the power outlet of the wall, the Barix devices, when using their default configuraton, will search for a DHCP server to get an IP address. If no DHCP Server is found, the device will try to sniff the network to find a "free" IP address. If that does not work either (because there are no other devices generating traffic), the device will pick an IP address of 169.254.x.x, according to the "Auto-IP" standard.
In any case, after max. 5 minutes the device will have an IP Address and announce it via the audio interface (headphone interface on encoding products).

* '''What if my routers don't have a fix IP address from the ISP (Internet service provider) ?'''
When your routers don't have a fix IP address and the dynamic IP address changes every day, then it makes sense to use a '''DNS name''' because you cannot change the configuration of the Instreamer / Exstreamer every day. DNS translates a unique name to a IP address. On the Internet there are some DNS registration services, '''DYNDNS.org''' is a very popular DNS service and supported from many routers.
Before you can use a DYNDNS – DNS name you have to create a account on www.dyndns.org, and select/register your DNS name. The account and the registration of a DNS name on DYNDNS is free of charge. The name should be a little more specific than 'myhome' and must be unique in the whole world. Once you have created your account and registered a valid DNS name then you have to configure your router so that the router updates the DYNDNS server every time when the router gets a new IP address from the ISP. Check first which services are supported on your router.

* ''' How do i connect a Barix device to HSPDA, UMTS, CDMA, EVDO, wireless networks ? ''' *
There is a special wiki article about that - please read this: [[Connecting to 3G Networks]]

* '''How do I configure the devices ?'''
You can adjust network settings, streaming destinations, monitoring settings and more with the Web interface. To enter the configuration mode you will need:
** the IP address announced over the audio outputs (see the Quick Install Guide)
** a standard web browser

* '''The device already has a password either I don't remember or I don't know, how do I erase it ?'''
Enter 25 characters to erase the current password and click on the "Apply" button. Then you can create a new one of up to 24 characters.

* '''Ho do I do a web update of a device ?'''
** download the software package you want to use
** unzip the package at your computer
** at the device press the update button
** click on the link: Please click here to continue
** press the browse button and navigate to the compound.bin file in the update_rescue folder
** press the upload button and wait for a successful message
** press on the update link
** press the reboot button and wait until the device has do a reboot
** refresh your browser page

Now the new software is loaded to the device.

* '''How do I set the device back to factory defaults ?'''
** Look for the "Defaults" button in the configuration page. This procedure will NOT erase the network settings.
** To revert ALL settings (including the network settings, passwords, etc) to factory defaults the “Reset” button has to be pressed for about 5 seconds while the Barix Instreamer is powered. Use this method if a connection to the Barix Instreamer cannot be established. If this fails we recommend to perform a “Serial Rescue”

* '''How do I perform a "Serial Rescue" of the device if it becomes unreachable ?'''
First of all you have to do this not by web browser but using a serial crossover cable.
Download the corresponding firmware package of the device from Barix' website as usual. Once the firmware is downloaded and unzipped, you will find the file called "_readme1st.txt". Please follow the instructions contained there.

The "Serial Rescue" loads the entire firmware and resets the device to factory default settings (current configuration is overwritten). It is therefore helpful to note the current setting. Printing out the “status” page is the quickest way as the page contains all configuration parameters.

* '''How do I get the "status page" of any device ?'''
Open your web browser and type in the IP address of the Barix device in the URL field followed by “/status” and hit the “Enter” key. • Example: “192.168.0.12/status”

* '''What if the device is still unreachable after a serial rescue ?'''
You can still use the "ARP" method to address the device, but for that you need a LOCAL connection.
After doing factory defaults, you can ALWAYS use the ARP method or serial method to set up an ip address to the unit and enter the configuration and re-enable it.
To use the arp-command to set an IP address to the Exstreamer manually, please do the following:
** connect power, loudspeaker and the cable to the device
** open a cmd console at your PC, using Windows do the following: "Start Button" --> "Execute" --> "cmd"
** type in "arp -s <ip address> <MAC address> (e.g. arp -s 192.168.0.201 00-08-e1-00-6c-e7)
** type in "telnet <ip address> 1 (e.g. telnet 192.168.0.201 1)
A connection will be initialised. After a short period (app. 2 seconds) you'll get an error message, that´s ok !!
Now the device has learned the ip address and you should be able to configure the device through your browser.

* '''What does RTP stand for ?'''
RTP means Real Time Protocol . The RTP is a stream of UDP frames that apart from audio content contains a small header with time sequence information. This information is used by the receiving party (e.g. Exstreamer) to detect and replace lost frames.

* '''AND what does BRTP stand for ?'''
BRTP is a modification of the RTP by Barix and works in pulling mode.

* '''How much latency should I expect in an Instreamer/Exstreamer setup using BTRP ?'''
We generally say '''"expect 500ms"''', it very much depends on the codec used, network bandwith - and very important, network jitter !
'''NOTE:''' the higher the encoding quality and bitrate, the better (lower) latency .. this sounds awkward but due to buffers being "shorter" in that case, it's true.

Best case about 200ms, if the network adds a lot, or you have to configure higher buffering (because of network jitter), then numbers are higher of course.

* '''How do emergency messages work ?'''
The way it works is that you can set up your Exstreamer or Annuncicom to look for a priority stream on a certain port. When it sees that stream, it disconnects the normal stream and subsitiutes the audio from the priority stream. When the priority stream goes away the unit automatically switches back to the original stream. There's even a separate volume control for the priority stream- so you can have music playing in the background at a low level and then sue the priority stream for emergency messages at a much louder level.

== Audio FAQ ==

=== Instreamer/ Encoding related questions ===

* '''Can the Instreamer also encode WMA ?'''
No. The Instreamer can encode only MP3, PCM or G711.

* '''Can the Instreamer also encode AACplus ?'''
No. The Instreamer can encode only MP3, PCM or G711.

* '''Do you have a product to encode AACplus (or a plan to do this ?)'''
No. There are no current plans to provide a product with AACplus encoding

* '''What kind of streams does the Instreamer produce ?'''
It converts audio from any analog or digital (optical/coaxial S/P DIF) source into:
** G.711 (aLaw/uLaw) streams at 8 or 24 kHz sample rate,
** PCM (16 bit) streams at 8 or 24 kHz sample rate or
** high-quality MP3 streams at adjustable bit rates (VBR) between 35 and 192kbps
** Encoding up to 48kHz PCM/stereo is possible with alternative firmware.
The audio is encoded in real-time, and the generated audio stream can be distributed, via an IP-based network or the Internet, to one or more receivers or Shoutcast / Icecast-servers.

* '''May I configure the stream EXACTLY at 64 kps (or some other value) on Instreamer 100 ?'''
The Instreamer generates VBR (variable bitrate), so an exact bitrate cannot be configured, but if you use the right settings the bitrate will average +-5% to a value near to or below 64kbps (or the desired value).

* '''How much bandwidth do I need to stream audio ?'''
The amount of bandwidth depends on the parameters you select on the Instreamer regarding encoding, quality and protocol. For mp3 the range is between 30 and 210 kbps. Example: At CD quality, each stream is approx 192kbps. FM Stereo is 128kbps.

If you want to do a linear feed (no perceptual coding), a 44.1 kHz PCM stream will consume most of a 1.544 mbit T1 line.

* '''How many destinations can I stream to ?'''
There are up to 8 direct destinations to stream to (or 32 in a specific configuration). Each one can be directed to a device, or a multi- or broadcast
address (destination connection types) or be set up as a listener waiting for a connection to be initiated by the other side (listener connection types). Each entry has its own IP address and Port. See [[Stream To Considerations]] on how to set the “Stream to” entries.

* '''Which is that specific configuration ?'''
'''BRTP''' This is a "pulling" RTP method, where the destination (Exstreamer) sends a request to the Instreamer and the Instreamer then sends the RTP stream. Big advantage: the Exstreamers can be using a DHCP address and they even can be behind NAT. Only the Instreamer needs a static IP address. Using this approach, up to 32 streams can origin from a single Instreamer (at 64kbps)

* '''But I need more than 32 destinations, how can I do ?'''
There are ways to address this, depending upon your situation and requirements:
For example, FM Stereo quality requires 128kbps of bandwidth so, for 100 destinations it will demand quite some bandwidth!
** If you do not have such capacity / don't want the headache of providing it and managing it, there are specialist firms such as Streamguys (www.streamguys.com) who can help - you send them the feed, they rebroadcast it.
** If you have the capacity, you can set up a shoutcast server and stream yourselves.
** A third option is our 'Replicator' software - We have written a software for the Barionet, which can receive an RTP stream and send it to up to 100 destinations (at 80kbps) with very low latency. The application can be managed/configured via web browser or it can pull a text file with the destinations from a server.

* '''I have set up multiple shoutcast destinations on my Instreamer. Can I use different passwords for different streams?'''
No, there is only one password common for all shoutcast destinations. If you need multiple passwords use an external shoutcast server and configure the Instreamer as Shoutcast Source streaming to this server.

* '''How do I set the Instreamer to feed streaming audio to a stream hosting company ?'''
In the streaming tab, scroll down to the middle of the page where there are eight 'stream to' boxes. In one of them select Shoutcast. In the boxes beside the Shoutcast, put in the IP address the stream hosting company resolves to. In the port box put the listen port number you use. Go to the bottom of the page and click apply.

Now, go to the security tab. There's a line to put a password that says Ice/Shoutcast. Put the password that the stream hosting company gave you here. Go to the bottom of the page and click apply.

Finally, you have to set your audio quality. In the audio tab select MP3 44.1 kbps and start out with a quality level of 2. Also select mono or stereo (mono will require less bandwidth than stereo). Check with the stream hosting company to make sure that you are at the bandwidth setting you bought with them but not over. If you are low, set the quality level to 3, if high, set the quality level to 1.

* '''I want to play the stream of an Instreamer with Windows Media Player, but it does not work'''
Windows Media Player can decode VBR MP3 streams as generated by the Instreamer, but in recent versions it does not calculate the buffering correctly. This is *not* a problem on the Barix side, it has been proven to be a problem with WMP.
There is a simple workaround: when WMP starts with "buffering", press the play button a second time and the stream will start playing.

* '''How do I configure a Instreamer-Exstreamer audio connection within the same LAN ?'''
You can download the [[Instreamer-Exstreamer How To]] PDF guide from the Downloads section of Barix site.

* '''How do I configure a Instreamer-Exstreamer audio connection over the Internet (known as STL connection)?'''
You can download the [[STL connection over Internet]] PDF guide from the Downloads section of Barix site.

* '''When using the Instreamer 100 to encode / feed a Shoutcast Server, how do I insert Artist / Title / Station-name text ?'''
Read [[how to send metadata]]

=== Exstreamer related questions ===
*'''SonicIP Voice - can i change this and record my own ?'''
Yes, to do so follow this [[SonicIP Howto]].

*'''[[How to use the Exstreamer 1000 as a PCM STL]] ?'''

*'''How do I play an AAC stream? What version of AAC do you support?'''
To play an AAC stream use an Exstreamer 110 labelled with "AAC+ capable" on the bottom. The software must be the Streaming Client 2.x (preloaded in the Exstreamer 110).

Both the [[wikipedia:Advanced Audio Coding|AAC (AAC LC)]] and [[wikipedia:AAC+|AAC+ (HE-AAC)]] are supported. In AAC+ both [[wikipedia:Spectral band replication|SBR]] (v1) and [[wikipedia:Parametric Stereo|PS]] (v2) are supported.

*'''How do I know what the LED blinking means ?'''
You can find that information in the "Exstreamer Technical Manual". (Faster [[Green and Red LED]])

*'''Can I download audio files from a remote server to be played ?'''
YES. There is an application called '''"FTP/HTTP store and forward MP3 player"''' contained in the ABCL-Kit Software (you can download it from Barix website www.barix.com). Basically it downloads playlists and MP3 files from a configured FTP or HTTP server to the local USB drive and plays them according to the configured time schedule (definable in the playlist). Features background update of mp3 files and playlists.

*'''How can I monitor an Exstreamer ?'''
For monitoring you can use the mtell-application. Please go to http://www.m-tell.de and click on the "create a new free demo project" link. In the mtell-settings you have to set the MAC address of the Exstreamer. Now you are able to sent the status of the device to the mtell-server. At the Exstreamer you have to set the MTEL URL to "http://www.m-tell.de" and the "MTELL Report Periode" to 5 seconds.

*'''What is the capacity of contact of the relay in an Exstreamer-1000 ?'''
24V - 0,5A

=== Annuncicom related questions ===
* '''Can I build an intercom system with Annuncicom?'''
Yes, use the PS16 as the central station. Follow this [[Barix Intercom System|howto]] to set up the system.

* '''What are the ratings for the relay on the Annuncicom ?'''
The ratings for the relay are: max 50V/1A

* '''Does the Annuncicom feature SIP functionality ?'''
Yes it does. To use the SIP application it is necessary to download the ABCL Kit. ABCL (Audio Barix Control Language) is a free programmable language like basic. The ABCL Kit includes a SIP Client for the Annuncicom. You can download it from the Download section of Barix website (Within "Software Solutions" category)

* '''Is an Annuncicom 100 with standard firmware able to receive audio using RTP protocol ?'''
Not with the standard firmware, but with the "Annuncicom Fullduplex" application contained in the ABCL kit.

=== IPAM related questions ===

* '''What is the difference between IPAM 200 and IPAM 300?'''
** IPAM 300 is an "upgrade" drop in replacement of the IPAM 200
** one more connector (4 pins) for I2S (digital output)
** no other hardware changes
** slightly better audio quality
** newer version of the DSP, can now also handle AACplus v2 (needs to be licensed if needed) and Ogg Vorbis
** runs the same software
** same price

== Control FAQ ==

=== X8 related questions ===
* '''How do i update an X8 with the latest firmware ?'''
You need a Barionet to do this. There is a special application for the Barionet which helps in doing this.
Here is a detailed howto page on this wiki describing this: [[X8-Update]]

=== Barionet related questions ===
* '''How do i read an I/O register using SNMP ?'''
All registers in the Barionet which hold I/O values can be read and written via SNMP. You can easily control the relays, for example, by using SNMP set requests on registers 1 and 2.

The detailed register map is documented in the Barionet manual.

How do the registers map to Object ID's ?

This is defined in the Barionet MIB, which is included in the device (you can access it with the URL /barionet.mib on the device), and on the Barix website.
Here is, for example, the OID for register 201 (digital input 1):

1.3.6.1.4.1.17491.1.1.2.1.2.201.0

Note the .0 at the end - and the number before is the register.

Defconlock

2009-01-28T22:30:23Z

Jrietschel:

Defconlock - Barix brands the Barionet with a preloaded access control application as a "Defconlock".

Currently, rudimentary/preliminary code is provided to those interested on a case by case basis, the product "Defconlock" is not yet finished. However, in this area on the wiki you can find code, pinouts, tips and tricks related to useing a wiegand reader with the Barionet

== Wiegand sample code ==
The sample code posted here opens the wiegand interface, a tcp listen socket, and then starts collecting wiegand scans of up to 2 readers connected directly to the Barionet. 26bit and 40bit cards are understood, decoded, and the resulting binary data is written into a "queue". If a host connects (or is connected) via TCP to the listening socket, it will receive the ID data and reader (1 or 2) information over the TCP connection.
Again - this is sample code, not a finished application. Use as you wish !

**** source code will be posted as soon as .zip/.bas uploads are possible ****

== Pinout / connection diagram for wiegand reader ==

Up to two Wiegand readers can be connected to a Defconlock/Barionet. Here is the recommended pinout to be used with the Defconlock application:

* Input 1 - Door contact
* Input 2 - Request to Exit
* Input 3 - Door Tamper contact
* Input 4 - Door locked
* Input 5 - D0 of first reader
* Input 6 - D1 of first reader
* Input 7 - (D0 of second reader, if used)
* Input 8 - (D1 of second reader, if used)
* Output 1 - Green LED control
* Output 2 - Red LED control
* Output 3 - Beeper control
* Output 4 - (local alarm, if used)

For a typical reader such as the HID Proxpoint Plus, this results in the following wiring

* J6 pin 1 .. pin 4 ... connected to door
* J6 pin 5: green
* J6 pin 6: white
* J6 pin 9: shield ground
* J6 pin 10: orange
* J6 pin 11: brown
* J6 pin 12: yellow
* J6 pin 13: blue
* J6 pin 14: black
* J6 pin 15: red (assuming Barionet is powered with less than 16V and reader can use that voltage)

How to send metadata to a shoutcast server

2009-01-27T20:17:47Z

Jrietschel:

A common question posted to the Barix support team is, "'''I am using an Instreamer to feed my shoutcast server, but how can i add metadata, genre, title information ?'''".

Well - this very much depends on how you operate your shoutcast server !

1) If the Instreamer is connected by the "shoutcast source" protocol - the instreamer actively connects to and sends the live audio feed to the server, then there is NO WAY the Instreamer can send that information with the audio ! The Shoutcast source protocol uses a "raw" TCP connection (after authentication) to send the MP3 frames, there is no way the Instreamer could insert that information. If you use that mode, you must directly post the metadata information via HTTP to the shoutcast/icecast server (check the server documentation).

2) If the Instreamer is operated in shoutcast/icecast emulation mode ("internet radio"), and your shoutcast/icecast server is configured as a "relay", then - and only then - you can feed metadata through the Instreamer.

Of course, that metadata cannot be sent through the analog or S/PDIF audio ports .. it needs to be provided to the Instreamer via the command interface, using raw TCP, UDP, serial port or the cgi interface.

To send metadata to the Instreamer for inclusion with the stream, please use the E= command. After the "E" parameter, you will need to supply standard shoutcast metadata format (documented somewhere else). Here is an example to post the Stream Title - note the command is case sensitive and must be correctly terminated (;) and quoted (single quotes).

'''http://<ip-instreamer>/rc.cgi?E=StreamTitle='Title';'''

Here is an example how the shoutcast server is configured as a relay - of course, this is just an incomplete snippet of the configuration file:

'''Shoutcast config:'''

RelayPort=8000

RelayServer=192.168.110.179 (Instreamer IP)

On the Instreamer, at least one "internet radio" server needs to be enabled.

How to send metadata

2009-01-27T20:06:16Z

Jrietschel: How to send metadata moved to How to send metadata to a shoutcast server: too short title

#REDIRECT [[How to send metadata to a shoutcast server]]

How to send metadata to a shoutcast server

2009-01-27T20:06:16Z

Jrietschel: How to send metadata moved to How to send metadata to a shoutcast server: too short title

To send metadata please use the E= command. After the "E" parameter, you should see the song´s title. The command is extreamely key sensitive. The right syntax is:

http://<ip-instreamer>/rc.cgi?E=StreamTitle='Title';

The Keyword: "StreamTitle" must be written as it is in the example. Please do not forget the " ' "signs and the " ; " at the end of the command.

The E= command work on Internet Radio mode. It could also sucessfully transfer the metadata through a Shoutcast server, when the Shoutcast Server works in the RELAY mode.

'''Shoutcast config:'''
RelayPort=8000
RelayServer=192.168.110.179 (Instreamer IP)

'''Instreamer Config:'''
Shoutcast Source : 0.0.0.0 : 8000

Barionet TCP Protocol v2

2009-01-25T20:24:02Z

Jrietschel:

The Barionet TCP Protocol Version 2 is still quite similar to version one.

It is implemented in the Barionet firmware from Version 2.30 onwards. Configuration/Selection is done via browser in the setup.
While the protocol is using the same commands as the previous version, there are some changes:

* it can be configured if the device sends status updates for relays, digital I/O and digital inputs by default (backward compatible)
* it can be configured if a "getio" command automatically subscribes (and subsequently, a "statechange" is sent)

Setting of I/O remains unchanged.

With both configuration options set (the recommended case), when a host connects to the Barionet, it defaults to "no active subscriptions", so no statechanges are sent. The host can now "prime" the interface by reading every interesting variable exactly once using the "getio" command. The answer will be returned as a "statechange" message, and subsequent changes of the variable will be reported, no further "getio" for the variable are needed.

If auto-subscription is not configured, the host can poll the variables using "getio" at its descretion, no status updates will be sent automatically (unless they are configured for the main I/O group).

The interface now supports long (signed) values. Digital I/O and analog values are still returned as short (unsigned) integers, however, values for temperature sensors, their ID's etc can be negative, same with the 701..1000 general registers.

When the host disconnects, the interface is reset to "no subscriptions".

"interval" is not any more supported, as a TCP connection is reliable, and it does not make much sense to send the status updates in regular intervals (it is still supported on the UDP interface).

Barionet TCP Protocol v2

2009-01-25T20:22:13Z

Jrietschel: New page: The Barionet TCP Protocol Version 2 is still quite similar to version one. It is implemented in the Barionet firmware from Version 2.30 onwards. Configuration/Selection is done via browse...

Barionet

2009-01-25T20:13:33Z

Jrietschel: New page: .. to be described. Here is a link to the description of the new version of the ASCII control protocol: Barionet TCP Protocol v2

.. to be described.

Here is a link to the description of the new version of the ASCII control protocol: [[Barionet TCP Protocol v2]]

Defconlock

2009-01-22T00:17:30Z

Jrietschel: New page: Defconlock - this page is under construction. == Pinout / connection diagram for wiegand reader == Up to two Wiegand readers can be connected to a Defconlock/Barionet. Here is the reco...

Defconlock - this page is under construction.

== Pinout / connection diagram for wiegand reader ==

Up to two Wiegand readers can be connected to a Defconlock/Barionet. Here is the recommended pinout to be used with the Defconlock application:

* Input 1 - Door contact
* Input 2 - Request to Exit
* Input 3 - Door Tamper contact
* Input 4 - Door locked
* Input 5 - D0 of first reader
* Input 6 - D1 of first reader
* Input 7 - (D0 of second reader, if used)
* Input 8 - (D1 of second reader, if used)
* Output 1 - Green LED control
* Output 2 - Red LED control
* Output 3 - Beeper control
* Output 4 - (local alarm, if used)

For a typical reader such as the HID Proxpoint Plus, this results in the following wiring

* J6 pin 1 .. pin 4 ... connected to door
* J6 pin 5: green
* J6 pin 6: white
* J6 pin 9: shield ground
* J6 pin 10: orange
* J6 pin 11: brown
* J6 pin 12: yellow
* J6 pin 13: blue
* J6 pin 14: black
* J6 pin 15: red (assuming Barionet is powered with less than 16V and reader can use that voltage)

Main Page

2009-01-22T00:08:23Z

Jrietschel: /* Barix Control Devices and accessories */

<big>'''Barix Wiki'''</big>

The Barix Wiki is maintained by Barix staff and users/community. Barix does try to keep the content accurate and error free, and we do review third party contributions, however, we can not guarantee everything is 100% accurate or up-to-date.
If you find any mistakes, errors etc. - please feel free to correct them !

== Sales & Marketing ==

== Applications ==
Barix products can be used in a vast variety of applications and markets. Below links bring you to pages which describe applications, which products to use etc
* [[Automation Applications]] - this includes data conversion, collection, remote managment and monitoring (non-audio) applications
* [[Broadcast Applications]] - Applications in the Broadcast Industry such as STL, internet radio, monitoring
* [[General Audio Distribution Applications]] - distribution of audio channels in hotels, over the internet, homes, amusement parks etc
* [[Alarm Applications]] - Use of the Barix products in emergency alerting applications
* [[SIP Applications]] - Use of the Barix products with SIP protocol for SIP speaker, intercom, phone applications
* [[Intercom Applications]] - specific page referring to Intercom Applications
* [[Crestron Integration]] - integrating audio over IP with Crestron touchpanels
* [[IP Intercom]] - a general description
* [[Rebroadcasting Application]] - what does it do ?

== Hardware Topics ==
* [[Software/Hardware compatibility matrix]]
* [[USB device compatibility list]]

== Software Topics ==

=== General Topics ===
* [[Multicast]] - how does multicast work with Barix products ?

=== Streaming Client ===
* [[Streaming Client howtos|Howtos]]
* [[Example configurations]]
* [[Windows Media streaming]] (MMS/WMA)
* [[Channel Selection]] To play different URL streams at different times
* [[Stream Switching]]

=== BCL Topics ===
* [[BCL programming tips]]

== Support, FAQ, Helpful information ==
=== Frequently Asked Questions (FAQ) ===
You will find many answers to common questions here!
* [[FAQ]] - general questions, sections about audio and control products
=== Troubleshooting ===
*[[USB_device_compatibility_list#USB_disk_troubleshooting_.28with_Streaming_Client_firmware.29|USB problems]]
*[[RS485 Termination]]
*[[WLAN Broadcast/Multicast]] - Problems using Broadcast over 802.11 WLAN infrastructure

== Products ==
=== Barix Audio Devices and Accessories ===
* [[Exstreamer 100]] - General Purpose Network Audio Decoder
* [[Exstreamer 110]] - Network Audio Decoder with advanced features
* [[Exstreamer 200]] - Network Audio Decoder with built-in 2x25W class-D amplifier
* [[Exstreamer 1000]] - High Quality Network Audio Encoder/Decoder with symmetric Audio interfaces and AES/EBU
* [[Instreamer 100]] - General Purpose Network Audio Encoder
* [[Annuncicom 100]] - General Purpose Bidirectional Network Audio Device with I/O
* [[Annuncicom 200]] - Network Audio Device suitable for intercom/paging applications with 8W output amplifier and PoE
* [[Annuncicom 1000]] - High End Network Audio Device for transport, industrial, security applications with balanced audio interfaces and supervised contact closures

* [[IPAM 100]]- Embedded IP audio module for OEM with dual network and multiple serial interfaces

* [[PS16]] - Multifunctional digital desktop paging station PS16
* [[VSC]] - Volume Source Control accessory

=== Barix Control Devices and accessories ===
* [[Barionet]] - General Purpose IP Automation Controller with SNMP and Modbus/TCP support, fully programmable. Various I/O capabilities
* [[Barionet 50]] - Low Cost IP Automation Controller with contact closure inputs, relay outputs, serial ports and Dallas Onewire interface
* [[Barionet 200]] - Advanced IP Automation Controller with 16bit analog inputs, analog outputs, RTC and USB flash drive support

* [[Defconlock]] - This is an application specific Barionet, preloaded with an Access Control application (app also separately downloadable)
* [[Barix TS]] - onewire temperature sensors

* [[Barix X8]] - multipurpose RS-485 I/O Interface

== Some useful links how to use the Wiki ==
Consult the [http://meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.

=== Getting started ===
* [http://www.mediawiki.org/wiki/Manual:Configuration_settings Configuration settings list]
* [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ]
* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]