Barix Wiki - User contributions [en]

Ethersound

2012-10-17T08:51:53Z

Brain: /* How to use a device in Ethersound mode */

== 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 from a central management software controlling as well the I/O on the device. 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]]

== How to use a device in Ethersound mode ==
=== Overview ===
The Ethersound software provided by Barix implements Slave speaker endpoints. For a complete system at least one audio source - Master - is needed. The (primary) Master also serves as an entry point for control commands. Through the Primary Master all Barix devices on the Ethersound network can be accessed using e.g. the ES-Control tool.

For more details about the read e.g. the [http://www.point-sourceaudio.com/network_audio/Digigram_EtherSound_Overview.pdf Ethersound Overview] document, chapters
3, 5 and 7.3.

=== Usage ===

Once you enter the Ethersound mode (after loading the proper software and selecting the Ethersound mode on the WEB UI) the device becomes accessible only through the Ethersound network. In Ethersound mode the WEB UI is not accessible and the device does not respond to IP.

To control the channel selection, audio and I/O use the ES-Control software, which is freely downloadable from [http://www.digigram.com/ Digigram homepage]. Please use ES-Control version 2.57 or later.

By default the volume is set to -20dB and no channel is selected. Therefore to hear audio the device must be configured at least once using ES-Control. This can be done e.g. by connecting a laptop with ES-Control to the Primary Master, discovering the network and configuring Barix devices. Once you finish the configuration, press "File->Save as power up mapping" to store the settings in the device's EEPROM. After that the managing PC is not needed any more, the configuration persists over reboot.

USB device compatibility list

2012-04-04T11:56:37Z

Brain: /* Filesystem version */

Most Barix devices feature an extension port for attaching USB 1.1 compatible mass storage devices (hard disks or FLASH disks).
This page describes compatibility and limitations of the extension port.

== Compatibility ==
The extension port supports:

* USB 1.1 and USB 2.0 (in USB 1.1 compatibility mode) devices
* only Mass Storage class devices
* HUBs are not supported (certain flash disks contain an embedded hub), the storage device needs to be connected directly
* "super floppy" formatted disks (without partition table) or the first primary FAT partition
* partition must be formatted as FAT12, FAT16 or FAT32

Most of the existing flash disks are supported. However, if you want to make sure that your flash disk is supported buy one from the below list.

===Filesystem version===
FAT 32 is supported since version 2.0 of the Filesystem.

To read the filesystem version on your device enter the IP address of your device into WEB browser followed by "/status" (e.g. "http://192.168.11.240/status") and search for "Fs version" on the Status page.

== 100% compatible flash disks ==

The below devices have been tested and proven to work:

{| border="1" cellpadding="3" cellspacing="0"
|'''Name'''
|'''Capacity'''
|'''USB version'''
|'''Vendor ID'''
|'''Model ID'''
|'''Manufacturer Name'''
|'''Product Name'''
|-
|A-Data "Show me disk" 1GB
|1GB
|2.0
|0x0457
|0x0151
| - not specified -
|USB Mass Storage Device
|-
|Barix 64MB Flash Disk
|64MB
|2.0
|0x090c
|0x1000
|SMI Corporation
|USB DISK
|-
|Barix 256MB Flash Disk
|256MB
|2.0
|0x1516
|0x8628
|Flash
|Drive AL_USB20
|-
|CBM 64MB
|64MB
|
|0x0204
|0x6025
|CBM
|Flash Disk
|-
|Creative NOMAD MuVo player
|64MB
|1.1
|0x041e
|0x4106
| - not specified -
| - not specified -
|-
|EMTEC Flash Drive 2GB
|2GB
|2.0
|0x13fe
|0x3100
| - not specified -
|USB DISK 2.0
|-
|Experient 32MB
|32MB
|1.1
|0x0204
|0x6025
|CBM
|Flash Disk
|-
|Information Tools pen
|64MB
|1.1
|0x058f
|0x9380
|Generic
|Mass Storage Device
|-
|Kingston DataTraveller 1GB
|1GB
|2.0
|
|
|
|
|-
|Kingston DataTraveller 256MB
|256MB
|2.0
|
|
|
|
|-
|niKKin Flash drive 1GB
|1GB
|2.0
|0x1516
|0x8628
|memory
|USB2.0
|-
|LEXAR JumpDrive 256MB
|256MB
|1.1
|0x05dc
|0x0080
|LEXAR MEDIA
|JUMPDRIVE
|-
|OCZ Rally 2 4GB
|4GB
|2.0
|
|
|
|
|-
|PIXIKA 512MB
|512MB
|2.0
|0x17ef
|0x3815
|PIXIKA
|
|-
|Pretec I-Disk Tiny 2.0 256MB
|256MB
|2.0
|0x0402
|0x5651
| - not specified -
|C-1 USB Storage Device
|-
|PQI 1GB USB2.0 flash disk
|1GB
|2.0
|
|
|
|
|-
|PQI Cool Drive U310 4GB
|4GB
|2.0
|0x3538
|0x0059
|PQI
|PQI USB Flash Drive
|-
|PQI Cool Drive U310 8GB
|8GB
|2.0
|0x3538
|0x0054
|PQI
|PQI USB Flash Drive
|-
|SanDisk Cruzer Micro 256
|256MB
|2.0
|
|
|
|
|-
|SanDisk Cruzer Micro 512
|512MB
|2.0
|
|
|
|
|-
|SanDisk Cruzer Mini 512
|512MB
|2.0
|
|
|
|
|-
|SanDisk Cruzer Crossfire
|1GB
|2.0
|0x0781
|0x5204
|SanDisk Corporation
|Cruzer Crossfire
|-
|Sony Micro Vault 4GB
|4GB
|2.0
|0x054c
|0x0243
|Sony
|Storage Media
|-
|Sony Micro Vault 2GB
|2GB
|2.0
|0x054c
|0x0243
|Sony
|Storage Media
|-
|STEC 256MB
|256MB
|2.0
|0x136b
|0x0918
|STEC
|STEC USB 256MB
|-
|Transcend Jet Flash 256
|256MB
|2.0
|0x058f
|0x6387
|Generic
|Mass Storage Device
|-
|Unknown 512MB
|512MB
|2.0
|0x0204
|0x6025
|CBM
|Flash Disk
|-
|Web Checkout 128MB
|128MB
|
|
|
|
|
|-
|}

The ''VendorID'', ''ModelID'' uniquely identify the device. They can be obtained e.g. on Linux using the [[wikipedia:lsusb|lsusb]] tool. You can find the database of Vendors on the internet, e.g. [http://www.linux-usb.org/usb.ids Linux USB Project].

The ''ManufacturerName'' and ''ProductName'' are the information obtained from the respective USB descriptors of the device and may differ to the name on the box (e.g. OEM FLASH disks).

== Incompatible devices ==
The following devices are not compatible with Barix devices:

* PNY Ataché 1GB
* LG 512MB USB drive

== How to buy a USB stick compatible with Barix devices ==
* buy devices listed in the compatibility table
* if the device is listed but another size is available it will most likely work
* if the device is not listed prefer the vendors from the list

Back to [[FAQ]]

Back to [[Troubleshooting]]

Back to [[Main Page]]

USB device compatibility list

2012-04-04T11:56:08Z

Brain: /* Compatibility */

Most Barix devices feature an extension port for attaching USB 1.1 compatible mass storage devices (hard disks or FLASH disks).
This page describes compatibility and limitations of the extension port.

== Compatibility ==
The extension port supports:

* USB 1.1 and USB 2.0 (in USB 1.1 compatibility mode) devices
* only Mass Storage class devices
* HUBs are not supported (certain flash disks contain an embedded hub), the storage device needs to be connected directly
* "super floppy" formatted disks (without partition table) or the first primary FAT partition
* partition must be formatted as FAT12, FAT16 or FAT32

Most of the existing flash disks are supported. However, if you want to make sure that your flash disk is supported buy one from the below list.

===Filesystem version===
FAT 32 is supported since version 2.0 of the Filesystem.

To read the filesystem version on your device enter the IP address of your device into WEB browser followed by "/status" and search for "Fs version" on the Status page.

== 100% compatible flash disks ==

The below devices have been tested and proven to work:

{| border="1" cellpadding="3" cellspacing="0"
|'''Name'''
|'''Capacity'''
|'''USB version'''
|'''Vendor ID'''
|'''Model ID'''
|'''Manufacturer Name'''
|'''Product Name'''
|-
|A-Data "Show me disk" 1GB
|1GB
|2.0
|0x0457
|0x0151
| - not specified -
|USB Mass Storage Device
|-
|Barix 64MB Flash Disk
|64MB
|2.0
|0x090c
|0x1000
|SMI Corporation
|USB DISK
|-
|Barix 256MB Flash Disk
|256MB
|2.0
|0x1516
|0x8628
|Flash
|Drive AL_USB20
|-
|CBM 64MB
|64MB
|
|0x0204
|0x6025
|CBM
|Flash Disk
|-
|Creative NOMAD MuVo player
|64MB
|1.1
|0x041e
|0x4106
| - not specified -
| - not specified -
|-
|EMTEC Flash Drive 2GB
|2GB
|2.0
|0x13fe
|0x3100
| - not specified -
|USB DISK 2.0
|-
|Experient 32MB
|32MB
|1.1
|0x0204
|0x6025
|CBM
|Flash Disk
|-
|Information Tools pen
|64MB
|1.1
|0x058f
|0x9380
|Generic
|Mass Storage Device
|-
|Kingston DataTraveller 1GB
|1GB
|2.0
|
|
|
|
|-
|Kingston DataTraveller 256MB
|256MB
|2.0
|
|
|
|
|-
|niKKin Flash drive 1GB
|1GB
|2.0
|0x1516
|0x8628
|memory
|USB2.0
|-
|LEXAR JumpDrive 256MB
|256MB
|1.1
|0x05dc
|0x0080
|LEXAR MEDIA
|JUMPDRIVE
|-
|OCZ Rally 2 4GB
|4GB
|2.0
|
|
|
|
|-
|PIXIKA 512MB
|512MB
|2.0
|0x17ef
|0x3815
|PIXIKA
|
|-
|Pretec I-Disk Tiny 2.0 256MB
|256MB
|2.0
|0x0402
|0x5651
| - not specified -
|C-1 USB Storage Device
|-
|PQI 1GB USB2.0 flash disk
|1GB
|2.0
|
|
|
|
|-
|PQI Cool Drive U310 4GB
|4GB
|2.0
|0x3538
|0x0059
|PQI
|PQI USB Flash Drive
|-
|PQI Cool Drive U310 8GB
|8GB
|2.0
|0x3538
|0x0054
|PQI
|PQI USB Flash Drive
|-
|SanDisk Cruzer Micro 256
|256MB
|2.0
|
|
|
|
|-
|SanDisk Cruzer Micro 512
|512MB
|2.0
|
|
|
|
|-
|SanDisk Cruzer Mini 512
|512MB
|2.0
|
|
|
|
|-
|SanDisk Cruzer Crossfire
|1GB
|2.0
|0x0781
|0x5204
|SanDisk Corporation
|Cruzer Crossfire
|-
|Sony Micro Vault 4GB
|4GB
|2.0
|0x054c
|0x0243
|Sony
|Storage Media
|-
|Sony Micro Vault 2GB
|2GB
|2.0
|0x054c
|0x0243
|Sony
|Storage Media
|-
|STEC 256MB
|256MB
|2.0
|0x136b
|0x0918
|STEC
|STEC USB 256MB
|-
|Transcend Jet Flash 256
|256MB
|2.0
|0x058f
|0x6387
|Generic
|Mass Storage Device
|-
|Unknown 512MB
|512MB
|2.0
|0x0204
|0x6025
|CBM
|Flash Disk
|-
|Web Checkout 128MB
|128MB
|
|
|
|
|
|-
|}

The ''VendorID'', ''ModelID'' uniquely identify the device. They can be obtained e.g. on Linux using the [[wikipedia:lsusb|lsusb]] tool. You can find the database of Vendors on the internet, e.g. [http://www.linux-usb.org/usb.ids Linux USB Project].

The ''ManufacturerName'' and ''ProductName'' are the information obtained from the respective USB descriptors of the device and may differ to the name on the box (e.g. OEM FLASH disks).

== Incompatible devices ==
The following devices are not compatible with Barix devices:

* PNY Ataché 1GB
* LG 512MB USB drive

== How to buy a USB stick compatible with Barix devices ==
* buy devices listed in the compatibility table
* if the device is listed but another size is available it will most likely work
* if the device is not listed prefer the vendors from the list

Back to [[FAQ]]

Back to [[Troubleshooting]]

Back to [[Main Page]]

USB device compatibility list

2012-04-04T11:51:04Z

Brain: /* USB disk troubleshooting (with Streaming Client firmware) - removed, obsolete */

Most Barix devices feature an extension port for attaching USB 1.1 compatible mass storage devices (hard disks or FLASH disks).
This page describes compatibility and limitations of the extension port.

== Compatibility ==
The extension port supports:

* USB 1.1 and USB 2.0 (in USB 1.1 compatibility mode) devices
* only Mass Storage class devices
* HUBs are not supported (certain flash disks contain an embedded hub), the storage device needs to be connected directly
* "super floppy" formatted disks (without partition table) or the first primary FAT partition
* partition must be formatted as FAT12, FAT16 or FAT32

Most of the existing flash disks are supported. However, if you want to make sure that your flash disk is supported buy one from the below list.

== 100% compatible flash disks ==

The below devices have been tested and proven to work:

{| border="1" cellpadding="3" cellspacing="0"
|'''Name'''
|'''Capacity'''
|'''USB version'''
|'''Vendor ID'''
|'''Model ID'''
|'''Manufacturer Name'''
|'''Product Name'''
|-
|A-Data "Show me disk" 1GB
|1GB
|2.0
|0x0457
|0x0151
| - not specified -
|USB Mass Storage Device
|-
|Barix 64MB Flash Disk
|64MB
|2.0
|0x090c
|0x1000
|SMI Corporation
|USB DISK
|-
|Barix 256MB Flash Disk
|256MB
|2.0
|0x1516
|0x8628
|Flash
|Drive AL_USB20
|-
|CBM 64MB
|64MB
|
|0x0204
|0x6025
|CBM
|Flash Disk
|-
|Creative NOMAD MuVo player
|64MB
|1.1
|0x041e
|0x4106
| - not specified -
| - not specified -
|-
|EMTEC Flash Drive 2GB
|2GB
|2.0
|0x13fe
|0x3100
| - not specified -
|USB DISK 2.0
|-
|Experient 32MB
|32MB
|1.1
|0x0204
|0x6025
|CBM
|Flash Disk
|-
|Information Tools pen
|64MB
|1.1
|0x058f
|0x9380
|Generic
|Mass Storage Device
|-
|Kingston DataTraveller 1GB
|1GB
|2.0
|
|
|
|
|-
|Kingston DataTraveller 256MB
|256MB
|2.0
|
|
|
|
|-
|niKKin Flash drive 1GB
|1GB
|2.0
|0x1516
|0x8628
|memory
|USB2.0
|-
|LEXAR JumpDrive 256MB
|256MB
|1.1
|0x05dc
|0x0080
|LEXAR MEDIA
|JUMPDRIVE
|-
|OCZ Rally 2 4GB
|4GB
|2.0
|
|
|
|
|-
|PIXIKA 512MB
|512MB
|2.0
|0x17ef
|0x3815
|PIXIKA
|
|-
|Pretec I-Disk Tiny 2.0 256MB
|256MB
|2.0
|0x0402
|0x5651
| - not specified -
|C-1 USB Storage Device
|-
|PQI 1GB USB2.0 flash disk
|1GB
|2.0
|
|
|
|
|-
|PQI Cool Drive U310 4GB
|4GB
|2.0
|0x3538
|0x0059
|PQI
|PQI USB Flash Drive
|-
|PQI Cool Drive U310 8GB
|8GB
|2.0
|0x3538
|0x0054
|PQI
|PQI USB Flash Drive
|-
|SanDisk Cruzer Micro 256
|256MB
|2.0
|
|
|
|
|-
|SanDisk Cruzer Micro 512
|512MB
|2.0
|
|
|
|
|-
|SanDisk Cruzer Mini 512
|512MB
|2.0
|
|
|
|
|-
|SanDisk Cruzer Crossfire
|1GB
|2.0
|0x0781
|0x5204
|SanDisk Corporation
|Cruzer Crossfire
|-
|Sony Micro Vault 4GB
|4GB
|2.0
|0x054c
|0x0243
|Sony
|Storage Media
|-
|Sony Micro Vault 2GB
|2GB
|2.0
|0x054c
|0x0243
|Sony
|Storage Media
|-
|STEC 256MB
|256MB
|2.0
|0x136b
|0x0918
|STEC
|STEC USB 256MB
|-
|Transcend Jet Flash 256
|256MB
|2.0
|0x058f
|0x6387
|Generic
|Mass Storage Device
|-
|Unknown 512MB
|512MB
|2.0
|0x0204
|0x6025
|CBM
|Flash Disk
|-
|Web Checkout 128MB
|128MB
|
|
|
|
|
|-
|}

The ''VendorID'', ''ModelID'' uniquely identify the device. They can be obtained e.g. on Linux using the [[wikipedia:lsusb|lsusb]] tool. You can find the database of Vendors on the internet, e.g. [http://www.linux-usb.org/usb.ids Linux USB Project].

The ''ManufacturerName'' and ''ProductName'' are the information obtained from the respective USB descriptors of the device and may differ to the name on the box (e.g. OEM FLASH disks).

== Incompatible devices ==
The following devices are not compatible with Barix devices:

* PNY Ataché 1GB
* LG 512MB USB drive

== How to buy a USB stick compatible with Barix devices ==
* buy devices listed in the compatibility table
* if the device is listed but another size is available it will most likely work
* if the device is not listed prefer the vendors from the list

Back to [[FAQ]]

Back to [[Troubleshooting]]

Back to [[Main Page]]

USB device compatibility list

2012-04-04T08:57:21Z

Brain: /* Limitations */

Most Barix devices feature an extension port for attaching USB 1.1 compatible mass storage devices (hard disks or FLASH disks).
This page describes compatibility and limitations of the extension port.

== Compatibility ==
The extension port supports:

* USB 1.1 and USB 2.0 (in USB 1.1 compatibility mode) devices
* only Mass Storage class devices
* HUBs are not supported (certain flash disks contain an embedded hub), the storage device needs to be connected directly
* "super floppy" formatted disks (without partition table) or the first primary FAT partition
* partition must be formatted as FAT12, FAT16 or FAT32

Most of the existing flash disks are supported. However, if you want to make sure that your flash disk is supported buy one from the below list.

== 100% compatible flash disks ==

The below devices have been tested and proven to work:

{| border="1" cellpadding="3" cellspacing="0"
|'''Name'''
|'''Capacity'''
|'''USB version'''
|'''Vendor ID'''
|'''Model ID'''
|'''Manufacturer Name'''
|'''Product Name'''
|-
|A-Data "Show me disk" 1GB
|1GB
|2.0
|0x0457
|0x0151
| - not specified -
|USB Mass Storage Device
|-
|Barix 64MB Flash Disk
|64MB
|2.0
|0x090c
|0x1000
|SMI Corporation
|USB DISK
|-
|Barix 256MB Flash Disk
|256MB
|2.0
|0x1516
|0x8628
|Flash
|Drive AL_USB20
|-
|CBM 64MB
|64MB
|
|0x0204
|0x6025
|CBM
|Flash Disk
|-
|Creative NOMAD MuVo player
|64MB
|1.1
|0x041e
|0x4106
| - not specified -
| - not specified -
|-
|EMTEC Flash Drive 2GB
|2GB
|2.0
|0x13fe
|0x3100
| - not specified -
|USB DISK 2.0
|-
|Experient 32MB
|32MB
|1.1
|0x0204
|0x6025
|CBM
|Flash Disk
|-
|Information Tools pen
|64MB
|1.1
|0x058f
|0x9380
|Generic
|Mass Storage Device
|-
|Kingston DataTraveller 1GB
|1GB
|2.0
|
|
|
|
|-
|Kingston DataTraveller 256MB
|256MB
|2.0
|
|
|
|
|-
|niKKin Flash drive 1GB
|1GB
|2.0
|0x1516
|0x8628
|memory
|USB2.0
|-
|LEXAR JumpDrive 256MB
|256MB
|1.1
|0x05dc
|0x0080
|LEXAR MEDIA
|JUMPDRIVE
|-
|OCZ Rally 2 4GB
|4GB
|2.0
|
|
|
|
|-
|PIXIKA 512MB
|512MB
|2.0
|0x17ef
|0x3815
|PIXIKA
|
|-
|Pretec I-Disk Tiny 2.0 256MB
|256MB
|2.0
|0x0402
|0x5651
| - not specified -
|C-1 USB Storage Device
|-
|PQI 1GB USB2.0 flash disk
|1GB
|2.0
|
|
|
|
|-
|PQI Cool Drive U310 4GB
|4GB
|2.0
|0x3538
|0x0059
|PQI
|PQI USB Flash Drive
|-
|PQI Cool Drive U310 8GB
|8GB
|2.0
|0x3538
|0x0054
|PQI
|PQI USB Flash Drive
|-
|SanDisk Cruzer Micro 256
|256MB
|2.0
|
|
|
|
|-
|SanDisk Cruzer Micro 512
|512MB
|2.0
|
|
|
|
|-
|SanDisk Cruzer Mini 512
|512MB
|2.0
|
|
|
|
|-
|SanDisk Cruzer Crossfire
|1GB
|2.0
|0x0781
|0x5204
|SanDisk Corporation
|Cruzer Crossfire
|-
|Sony Micro Vault 4GB
|4GB
|2.0
|0x054c
|0x0243
|Sony
|Storage Media
|-
|Sony Micro Vault 2GB
|2GB
|2.0
|0x054c
|0x0243
|Sony
|Storage Media
|-
|STEC 256MB
|256MB
|2.0
|0x136b
|0x0918
|STEC
|STEC USB 256MB
|-
|Transcend Jet Flash 256
|256MB
|2.0
|0x058f
|0x6387
|Generic
|Mass Storage Device
|-
|Unknown 512MB
|512MB
|2.0
|0x0204
|0x6025
|CBM
|Flash Disk
|-
|Web Checkout 128MB
|128MB
|
|
|
|
|
|-
|}

The ''VendorID'', ''ModelID'' uniquely identify the device. They can be obtained e.g. on Linux using the [[wikipedia:lsusb|lsusb]] tool. You can find the database of Vendors on the internet, e.g. [http://www.linux-usb.org/usb.ids Linux USB Project].

The ''ManufacturerName'' and ''ProductName'' are the information obtained from the respective USB descriptors of the device and may differ to the name on the box (e.g. OEM FLASH disks).

== Incompatible devices ==
The following devices are not compatible with Barix devices:

* PNY Ataché 1GB
* LG 512MB USB drive

== How to buy a USB stick compatible with Barix devices ==
* buy devices listed in the compatibility table
* if the device is listed but another size is available it will most likely work
* if the device is not listed prefer the vendors from the list

== USB disk troubleshooting (with Streaming Client firmware) ==

If your disk is not recognised, make sure that it is properly formatted and partitioned. Some USB sticks come pre-formatted without any partitions. On Linux you can see that the disk appears e.g. as /dev/sda rather than /dev/sda1. If this is the case the USB disk will not be recognised by the Barix device.

To solve this problem create primary partition nr. 1 (using fdisk on Linux) and format it to FAT16.

Is the USB disk not recognised by a Barix unit? This procedure may help you to find the reason:
* open the WEB UI of the Barix unit in your browser and type ''/status'' after the IP address
* scroll down to "''USB device info''"
* check if the "''Filesystem type'' is "FAT16". If it is "FAT32" reformat the disk to FAT16

Back to [[FAQ]]

Back to [[Troubleshooting]]

Back to [[Main Page]]

RTP Buffering - Frame Based Buffering

2011-10-18T09:21:40Z

Brain: corrected swapped PCM 44.1 kHz mono and 44.1kHz stereo labels

== Introduction ==
In Song module version 8 a new RTP buffering method called '''frame based buffering''' was introduced.
The algorithm calculates the audio buffer level in milliseconds rather than in bytes.

== Features ==
Frame based buffering allows:
* configurable decoding delay with one frame accuracy
* synchronisation of several decoders to the same stream (just by configuring them to the same initial delay)
* stable delay over long period of time
* automatic correction of clock difference between encoder and decoder

== Applications ==
The following applications use frame based buffering:
{| border="1" cellpadding="3" cellspacing="0"
|-
|'''Application Name'''
|'''Version'''
|-
| Streaming Client
|align="right"| 2.17
|-
| Annuncicom Full Duplex
|align="right"| 0.21
|-
| RTP STL
|align="right"| 2.01
|-
|}

== Configuration ==

The only configuration parameter for the RTP decoder is the '''delay''' in milliseconds.

The delay parameter is the desired processing delay of the decoder (between the network input and the audio output). Please note that the end-to-end delay between the encoder and the decoder might be (significantly) different to the value configured.

In an ideal case the delay parameter would be 0 ms, however due to device's internal buffers a small delay (depending on the hardware) is inevitable. The delay value should also cover possible temporary network hick-ups (jitter). E.g. if the network sometimes delays the packet delivery by 20ms due to a temporary load, the configured parameter should not be less than 20ms.

The maximum configurable delay is limited by the device's internal buffer (64, 32 or 16kB).

=== Recommended Settings ===
The following table lists recommended delay values for various audio formats. The value includes 2-frame jitter and is independent on hardware/software.

{| border="1" cellpadding="3" cellspacing="0"
|-
|'''Audio format'''
|'''Delay'''
|-
| MP3
| 600ms
|-
| uLaw/ALaw 8kHz mono
| 444ms
|-
| PCM 8kHz mono
| 444ms
|-
| uLaw/ALaw 12kHz mono
| 316ms
|-
| PCM 12kHz mono
| 316ms
|-
| uLaw/ALaw 24kHz mono
| 188ms
|-
| PCM 24kHz mono
| 188ms
|-
| uLaw/ALaw 32kHz mono
| 156ms
|-
| PCM 32kHz mono
| 152ms
|-
| PCM 44.1kHz mono
| 110ms
|-
| PCM 44.1kHz stereo
| 79ms
|-
| PCM 48kHz stereo
| 72ms
|-
|}

=== Maximum Settings ===
This section explains the minimum and the maximum delay values for different audio formats and platforms.

The hardware is divided into two groups:
* '''Micronas (MAS) based devices:''' Annuncicom 100/155/200/1000, Exstreamer 1000
* '''VLSI based devices:''' Exstreamer 100/110/200

====MP3 CBR====
The following table shows the minimum and the maximum possible delay with MP3 constant bitrate. The maximum delay differs between the Streaming Client, which has 64kB audio buffer available, and ABCL (Annuncicom FDX, STL), which features only 32kB buffer. The minimum delay includes 100ms network jitter.

{| border="1" cellpadding="3" cellspacing="0"
|-
|'''MP3 CBR bitrate'''
|'''Min delay'''
|'''Max delay (SC)'''
|'''Max delay (ABCL)'''
|-
| 320kbps
| 150ms
| 1,588ms
| 769ms
|-
| 256kbps
| 163ms
| 2,011ms
| 987ms
|-
| 192kbps
| 183ms
| 2,741ms
| 1,349ms
|-
| 160kbps
| 200ms
| 3,277ms
| 1,638ms
|-
| 128kbps
| 225ms
| 4,121ms
| 2,073ms
|-
| 64kbps
| 350ms
| 8,342ms
| 4,246ms
|-
| 32kbps
| 600ms
| 16,784ms
| 8,592ms
|-
|}

====MP3 VBR and ABR====
Variable or average bitrate the minimum and delay depends on the bitrate variation interval. The minimum delay is taken from the CBR table for the low end of the interval, whereas the maximum delay is the CBR value for the high end of the interval.

Please note that most MP3 encoders use the whole bitrate range starting from the lowest bitrate 32kbps. E.g. VBR 128kbps varies from 32 to 128kbps

{| border="1" cellpadding="3" cellspacing="0"
|-
|'''MP3 Format'''
|'''Min delay'''
|'''Max delay (SC)'''
|'''Max delay (ABCL)'''
|-
| 32-320kbps
| 600ms
| 1,588ms
| 769ms
|-
| 32-256kbps
| 600ms
| 2,011ms
| 987ms
|-
| 32-192kbps
| 600ms
| 2,741ms
| 1,349ms
|-
| 32-160kbps
| 600ms
| 3,277ms
| 1,638ms
|-
| 32-128kbps
| 600ms
| 4,121ms
| 2,073ms
|-
| 32-64kbps
| 600ms
| 8,342ms
| 4,246ms
|-
|}

====PCM====
In uncompressed audio (PCM, uLaw or ALaw) the minimum and maximum delay depend on the bit rate and on the hardware.

The following table lists minimum and maximum settings for all standard RTP audio formats:
{| border="1" cellpadding="3" cellspacing="0"
|-
|'''Format'''
|'''Min delay MAS'''
|'''Min delay VLSI'''
|'''Max delay (SC)'''
|'''Max delay (ABCL)'''
|'''Max delay (ABCL full duplex)'''
|-
| uLaw 8kHz mono 
ALaw 8kHz mono
| 80ms
| 424ms
| 8171ms
| 4075ms
| 2027ms
|-
| PCM 8kHz mono
| 60ms
| 424ms
| 4075ms
| 2027ms
| 1003ms
|-
| uLaw 12kHz mono 
ALaw 12kHz mono
| 67ms
| 296ms
| 5441ms
| 2710ms
| 1345ms
|-
| PCM 12kHz mono
| 54ms
| 296ms
| 2710ms
| 1345ms
| 662ms
|-
| uLaw 24kHz mono 
ALaw 24kHz mono
| 54ms
| 168ms
| 2710ms
| 1345ms
| 662ms
|-
| PCM 24kHz mono
| 47ms
| 168ms
| 1345ms
| 662ms
| 321ms
|-
| uLaw 32kHz mono 
ALaw 32kHz mono
| 50ms
| 136ms
| 2027ms
| 1003ms
| 491ms
|-
| PCM 32kHz mono
| 43ms
| 134ms
| 1005ms
| 493ms
| 237ms
|-
| PCM 44.1kHz mono
| 31ms
| 97ms
| 729ms
| 358ms
| 172ms
|-
| PCM 44.1kHz stereo
| 16ms
| 72ms
| 364ms
| 179ms
| 86ms
|-
| PCM 48kHz stereo
| 15ms
| 66ms
| 335ms
| 164ms
| 79ms
|-
|}

== Multiple Device Synchronisation ==
Multiple devices receiving the same RTP stream can be configured to play in sync by entering the same delay parameter.

Barix recommends to use broadcast or multicast together with synchronisation, otherwise a small inaccuracy (few milliseconds) might be caused by the network delivery to different locations.

== Deliberate Delays ==
In some applications it is desired to artificially delay the audio. E.g. in a tunnel to eliminate the delay caused by the distance between the devices.

An artificial delay can be introduced by configuring the devices to different delay values. E.g. 100ms, 120ms, 140ms, 160ms, etc.

RTP Buffering - Frame Based Buffering

2011-10-18T09:21:08Z

Brain: corrected swapped 44.1 kHz mono and 44.1kHz stereo labels

== Introduction ==
In Song module version 8 a new RTP buffering method called '''frame based buffering''' was introduced.
The algorithm calculates the audio buffer level in milliseconds rather than in bytes.

== Features ==
Frame based buffering allows:
* configurable decoding delay with one frame accuracy
* synchronisation of several decoders to the same stream (just by configuring them to the same initial delay)
* stable delay over long period of time
* automatic correction of clock difference between encoder and decoder

== Applications ==
The following applications use frame based buffering:
{| border="1" cellpadding="3" cellspacing="0"
|-
|'''Application Name'''
|'''Version'''
|-
| Streaming Client
|align="right"| 2.17
|-
| Annuncicom Full Duplex
|align="right"| 0.21
|-
| RTP STL
|align="right"| 2.01
|-
|}

== Configuration ==

The only configuration parameter for the RTP decoder is the '''delay''' in milliseconds.

The delay parameter is the desired processing delay of the decoder (between the network input and the audio output). Please note that the end-to-end delay between the encoder and the decoder might be (significantly) different to the value configured.

In an ideal case the delay parameter would be 0 ms, however due to device's internal buffers a small delay (depending on the hardware) is inevitable. The delay value should also cover possible temporary network hick-ups (jitter). E.g. if the network sometimes delays the packet delivery by 20ms due to a temporary load, the configured parameter should not be less than 20ms.

The maximum configurable delay is limited by the device's internal buffer (64, 32 or 16kB).

=== Recommended Settings ===
The following table lists recommended delay values for various audio formats. The value includes 2-frame jitter and is independent on hardware/software.

{| border="1" cellpadding="3" cellspacing="0"
|-
|'''Audio format'''
|'''Delay'''
|-
| MP3
| 600ms
|-
| uLaw/ALaw 8kHz mono
| 444ms
|-
| PCM 8kHz mono
| 444ms
|-
| uLaw/ALaw 12kHz mono
| 316ms
|-
| PCM 12kHz mono
| 316ms
|-
| uLaw/ALaw 24kHz mono
| 188ms
|-
| PCM 24kHz mono
| 188ms
|-
| uLaw/ALaw 32kHz mono
| 156ms
|-
| PCM 32kHz mono
| 152ms
|-
| PCM 44.1kHz mono
| 110ms
|-
| PCM 44.1kHz stereo
| 79ms
|-
| PCM 48kHz stereo
| 72ms
|-
|}

=== Maximum Settings ===
This section explains the minimum and the maximum delay values for different audio formats and platforms.

The hardware is divided into two groups:
* '''Micronas (MAS) based devices:''' Annuncicom 100/155/200/1000, Exstreamer 1000
* '''VLSI based devices:''' Exstreamer 100/110/200

====MP3 CBR====
The following table shows the minimum and the maximum possible delay with MP3 constant bitrate. The maximum delay differs between the Streaming Client, which has 64kB audio buffer available, and ABCL (Annuncicom FDX, STL), which features only 32kB buffer. The minimum delay includes 100ms network jitter.

{| border="1" cellpadding="3" cellspacing="0"
|-
|'''MP3 CBR bitrate'''
|'''Min delay'''
|'''Max delay (SC)'''
|'''Max delay (ABCL)'''
|-
| 320kbps
| 150ms
| 1,588ms
| 769ms
|-
| 256kbps
| 163ms
| 2,011ms
| 987ms
|-
| 192kbps
| 183ms
| 2,741ms
| 1,349ms
|-
| 160kbps
| 200ms
| 3,277ms
| 1,638ms
|-
| 128kbps
| 225ms
| 4,121ms
| 2,073ms
|-
| 64kbps
| 350ms
| 8,342ms
| 4,246ms
|-
| 32kbps
| 600ms
| 16,784ms
| 8,592ms
|-
|}

====MP3 VBR and ABR====
Variable or average bitrate the minimum and delay depends on the bitrate variation interval. The minimum delay is taken from the CBR table for the low end of the interval, whereas the maximum delay is the CBR value for the high end of the interval.

Please note that most MP3 encoders use the whole bitrate range starting from the lowest bitrate 32kbps. E.g. VBR 128kbps varies from 32 to 128kbps

{| border="1" cellpadding="3" cellspacing="0"
|-
|'''MP3 Format'''
|'''Min delay'''
|'''Max delay (SC)'''
|'''Max delay (ABCL)'''
|-
| 32-320kbps
| 600ms
| 1,588ms
| 769ms
|-
| 32-256kbps
| 600ms
| 2,011ms
| 987ms
|-
| 32-192kbps
| 600ms
| 2,741ms
| 1,349ms
|-
| 32-160kbps
| 600ms
| 3,277ms
| 1,638ms
|-
| 32-128kbps
| 600ms
| 4,121ms
| 2,073ms
|-
| 32-64kbps
| 600ms
| 8,342ms
| 4,246ms
|-
|}

====PCM====
In uncompressed audio (PCM, uLaw or ALaw) the minimum and maximum delay depend on the bit rate and on the hardware.

The following table lists minimum and maximum settings for all standard RTP audio formats:
{| border="1" cellpadding="3" cellspacing="0"
|-
|'''Format'''
|'''Min delay MAS'''
|'''Min delay VLSI'''
|'''Max delay (SC)'''
|'''Max delay (ABCL)'''
|'''Max delay (ABCL full duplex)'''
|-
| uLaw 8kHz mono 
ALaw 8kHz mono
| 80ms
| 424ms
| 8171ms
| 4075ms
| 2027ms
|-
| PCM 8kHz mono
| 60ms
| 424ms
| 4075ms
| 2027ms
| 1003ms
|-
| uLaw 12kHz mono 
ALaw 12kHz mono
| 67ms
| 296ms
| 5441ms
| 2710ms
| 1345ms
|-
| PCM 12kHz mono
| 54ms
| 296ms
| 2710ms
| 1345ms
| 662ms
|-
| uLaw 24kHz mono 
ALaw 24kHz mono
| 54ms
| 168ms
| 2710ms
| 1345ms
| 662ms
|-
| PCM 24kHz mono
| 47ms
| 168ms
| 1345ms
| 662ms
| 321ms
|-
| uLaw 32kHz mono 
ALaw 32kHz mono
| 50ms
| 136ms
| 2027ms
| 1003ms
| 491ms
|-
| PCM 32kHz mono
| 43ms
| 134ms
| 1005ms
| 493ms
| 237ms
|-
| PCM 44.1kHz stereo
| 31ms
| 97ms
| 729ms
| 358ms
| 172ms
|-
| PCM 44.1kHz mono
| 16ms
| 72ms
| 364ms
| 179ms
| 86ms
|-
| PCM 48kHz stereo
| 15ms
| 66ms
| 335ms
| 164ms
| 79ms
|-
|}

== Multiple Device Synchronisation ==
Multiple devices receiving the same RTP stream can be configured to play in sync by entering the same delay parameter.

Barix recommends to use broadcast or multicast together with synchronisation, otherwise a small inaccuracy (few milliseconds) might be caused by the network delivery to different locations.

== Deliberate Delays ==
In some applications it is desired to artificially delay the audio. E.g. in a tunnel to eliminate the delay caused by the distance between the devices.

An artificial delay can be introduced by configuring the devices to different delay values. E.g. 100ms, 120ms, 140ms, 160ms, etc.

Bit-reservoir issues

2011-05-03T12:28:36Z

Brain: /* Bit-reservoir in streaming */

== What is bit-reservoir ==

One of the features of the MP3 format is so called '''bit-reservoir''', which can be simply explained as storing information from one frame to the next frame. If an MP3 file or stream is encoded with bit-reservoir feature enabled then the consecutive frames depend on each other. Otherwise they are completely self-contained.

The bit-reservoir feature slightly reduces the overall size of the file.

== Bit-reservoir in streaming ==

In RTP streaming it is desired that consecutive frames are independent. Otherwise, if a packet is lost, the next one or more frames cannot be properly decoded by the receiver, which results, depending on the decoder, either in noise (glitches) or silence.

On [[Instreamer 100 | Instreamer]] the bit-reservoir is configurable. Disable it when streaming RTP.

== Streaming files ==

PC files are usually encoded with bit-reservoir enabled. Therefore if you decide to stream files, make sure that you create the files for streaming without bit-reservoir. You can also re-encode your existing files using e.g. Lame:

lame --nores original_file.mp3 new_file_without_bit_reservoir.mp3

Bit-reservoir issues

2011-05-03T12:27:19Z

Brain: New page: == What is bit-reservoir == One of the features of the MP3 format is so called '''bit-reservoir''', which can be simply explained as storing information from one frame to the next frame. ...

== What is bit-reservoir ==

One of the features of the MP3 format is so called '''bit-reservoir''', which can be simply explained as storing information from one frame to the next frame. If an MP3 file or stream is encoded with bit-reservoir feature enabled then the consecutive frames depend on each other. Otherwise they are completely self-contained.

The bit-reservoir feature slightly reduces the overall size of the file.

== Bit-reservoir in streaming ==

In RTP streaming it is desired that consecutive frames are independent. Otherwise, if a packet is lost, the next one or more frames cannot be properly decoded by the receiver, which results, depending on the decoder, either in noise (glitches) or silence.

On [[Instreamer]] the bit-reservoir is configurable. Disable it when streaming RTP.

== Streaming files ==

PC files are usually encoded with bit-reservoir enabled. Therefore if you decide to stream files, make sure that you create the files for streaming without bit-reservoir. You can also re-encode your existing files using e.g. Lame:

lame --nores original_file.mp3 new_file_without_bit_reservoir.mp3

FAQ

2011-05-03T12:16:10Z

Brain: /* Questions related to audio formats in general */

== 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)
* '''[[Bit-reservoir issues]]'''

=== 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

*'''They have to feed the input of relay contacts?. How much ?'''

=== 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]]

Streaming RTP from PC to Barix Devices

2011-02-08T10:12:14Z

Brain: /* Using FFmpeg */

Quite often there is a need to stream from a PC to Barix devices. The most convenient and most standard way is to use RTP.

Barix offers several tools for streaming RTP.

= MP3 RTP Streamer =
MP3 RTP Streamer is an interactive Java tool, that can run on Windows, Linux or MAC. You can download it from Barix Website:
[http://www.barix.com/downloads/Software_tools/221/ Downloads:Software tools]
Read the User Manual for further instructions to use.

= MP32RTP =

Is a command-line tool for Linux distributed under GPL. Can be downloaded from Barix Website:
[http://www.barix.com/downloads/Software_tools/221/ Downloads:Software tools]

MP32RTP parses an MP3 file on standard input and sends as RTP to a Barix Device specified by IP address a port.
Usage:

mp32rtp -i IP ADDRESS -p PORT < FILE.MP3

= Using FFmpeg =
Sometimes it is necessary to re-encode the media file or convert from a different file before sending via RTP.

The program [http://www.ffmpeg.org/ ffmpeg] is and option for such conversion. It has an option to send directly RTP frames, however this is not supported by Barix devices. To re-encode a file and stream via RTP use ffmpeg together with mp32rtp as follows:

ffmpeg -re -i FILE.MP3 -acodec libmp3lame -ab128k -ar 44100 -ac 2 -f mp3 - | \
mp32rtp -i IPADDRESS -p PORT

Streaming Client

2011-02-08T08:47:32Z

Brain:

* [[Streaming Client howtos|Howtos]]
* [[Example configurations]]
* [[Windows Media streaming]] (MMS/WMA)
* [[Channel Selection]] To play different URL streams at different times
* [[Stream Switching]]
* [[VSC support in the Streaming Client]]
* [[Howto remove scrolling title from the Exstreamer 110 display]]
* [[Streaming RTP from PC to Barix Devices]]

Back to [[Main_Page#Software_Topics]]

Streaming Client

2011-02-08T08:43:10Z

Brain:

* [[Streaming Client howtos|Howtos]]
* [[Example configurations]]
* [[Windows Media streaming]] (MMS/WMA)
* [[Channel Selection]] To play different URL streams at different times
* [[Stream Switching]]
* [[VSC support in the Streaming Client]]
* [[Howto remove scrolling title from the Exstreamer 110 display]]
* [[Streaming RTP from Linux to Barix Devices]]

Back to [[Main_Page#Software_Topics]]

Streaming Client

2011-02-08T08:38:39Z

Brain:

* [[Streaming Client howtos|Howtos]]
* [[Example configurations]]
* [[Windows Media streaming]] (MMS/WMA)
* [[Channel Selection]] To play different URL streams at different times
* [[Stream Switching]]
* [[VSC support in the Streaming Client]]
* [[Howto remove scrolling title from the Exstreamer 110 display]]
* [[Streaming RTP from ffmpeg to Barix]]

Back to [[Main_Page#Software_Topics]]

AutoIP Howto

2010-09-01T12:41:32Z

Brain: /* IPzator */

== Static IP vs. automatic IP ==

There are two ways of configuring IP parameters of a device: '''static''' and '''dynamic''' configuration.

== Static IP address ==

The simplest (but not always the easiest) method is to assign a static IP address. You need to set the following parameters in the Network section of the WEB UI of the device:
* '''IP address'''
* '''netmask'''
* gateway
* primary DNS server
* secondary (backup) DNS server

The first two (bold) parameters are the minimum for communication within a LAN. If the device needs an access to the outside world, the '''gateway''' must be configured as well. If you are using name addresses, one or better both DNS servers must be configured.

===Benefits of a static IP address configuration===
* '''the address does not change'''
* no special server is needed

===Disadvantages===
* you need to configure every device separately - which can be a problem with a large number of units
* no simple way of management - if you need to change the address you have to go to every single device
* more addresses needed if clients "come and go" - this may be a problem if there is only a limited number of IP addresses available

== Automatic IP address assignment using a server ==

Alternatively, one or more of the above parameters can be assigned automatically using a '''central server'''.

There are two common methods/protocols for automatic assignment of an IP address using a central server: the older [[wikipedia:BOOTP|BOOTP]] and widely used [[wikipedia:DHCP|DHCP]].

With DHCP typically all the above network parameters (IP address, netmask, gateway, DNS servers) are set, whereas BOOTP can set only the IP address and gateway address.

===Benefits===
* centralised management
* almost zero configuration at the client
* dynamic configuration - the client can come and go (e.g. a laptop)

===Disadvantages===
* requires a server - a problem if the server is down
* the address may change (depends on the configuration of the server) - this can be a problem if the unit is accessed "from the outside world"

=== Combined solution: "static" dynamic addresses===
A DHCP server can be configured to assign always the same address to a specific client. The client identifies itself with its Ethernet MAC address.

This method combines the benefits of both solutions: a simple central management and at the same time an address which does not change

==AutoIP and IPzator==
If there is no DHCP/BOOTP server available the IP address can be "guessed" using one of the methods: '''AutoIP''' or '''IPzator'''

Both these methods attempt to discover a free IP address on the network if all the above methods have failed. '''They should not be used as a primary configuration but only as a fail-over mechanism!'''

These methods are not 100% reliable and can cause an IP address collision on the network.

===IPzator===
This method listens on the attached network and tries to find:
* the network address of the attached network, netmask is assumed from the network adddress (A, B and C class network)
* a free IP address on this network

It sets the IP address and the netmask (always 255.255.255.0). The gateway address and the DNS address are left intact.

'''NOTE:''' '''It may take up to 3 minutes to find a free address!'''

'''NOTE:''' If an IP address is assigned by IPzator but this address is used by some other host on the network, which is not active or switched off, an IP address collision can occur if the inactive host becomes on-line.

We send an ARP to ourselves ("gratitious arp") every 3 minutes to detect IP address conflicts and also inform others automatically about the IP (if they listen).
If there is another device answering to this request, we instantly go off the network, the LEDs show 5x green blinking (and red LED is typically on), after 15 seconds, the device reboots, in the hope to get a different IP address from a DHCP server.

===AutoIP===
Automatically assigns a free IP address in the network 169.254.0.0/16. It sets the IP address and the netmask (always 255.255.0.0). Gateway address and DNS address are left intact.

This is the last method used if all the above methods fail.

==How to configure==
A static IP address is simply configured by filling the four IP address fields and the other network parameters in the network configuration of a device.

An automatic IP address is selected by setting the IP address to 0.0.0.0.

'''NOTE:''' If automatic IP address is configured, netmask, gateway address (DHCP or BOOTP only) and DNS server addresses (DHCP only) are overwritten.

===Auto IP discovery order===
The four mentioned methods of obtaining an IP address automatically are executed in the following order:
#BOOTP
#DHCP
#IPzator
#AutoIP

The first successful method stops the process.

===Selecting specific auto IP methods===
Each of the above methods can be enabled or disabled. By default all are enabled. A method is disabled by setting a specific bit in the third field of the IP address:
* “0.0.1.0” to disable AutoIP
* “0.0.2.0” to disable DHCP
* “0.0.4.0” to disable BOOTP
* “0.0.8.0” to disable IPzator

Examples:
* “0.0.3.0” disables AutoIP and DHCP
* “0.0.11.0” disables all but BOOTP

'''ATTENTION:''' “0.0.15.0” disables all discovery functions which locks you out unless you reset the device to factory defaults by pressing the reset button for about 10 seconds.

==Automatic IP address configuration notes==
If you configure a device to automatically obtain an IP address you should know that:
* if the device is not connected to the network or the network is lost at the boot-up time it might take up to 5 minutes before the unit becomes ready!

Back to [[FAQ]]

RTP Buffering - Frame Based Buffering

2010-06-24T09:51:57Z

Brain: /* Recommended Settings */

== Introduction ==
In Song module version 8 a new RTP buffering method called '''frame based buffering''' was introduced.
The algorithm calculates the audio buffer level in milliseconds rather than in bytes.

== Features ==
Frame based buffering allows:
* configurable decoding delay with one frame accuracy
* synchronisation of several decoders to the same stream (just by configuring them to the same initial delay)
* stable delay over long period of time
* automatic correction of clock difference between encoder and decoder

== Applications ==
The following applications use frame based buffering:
{| border="1" cellpadding="3" cellspacing="0"
|-
|'''Application Name'''
|'''Version'''
|-
| Streaming Client
|align="right"| 2.17
|-
| Annuncicom Full Duplex
|align="right"| 0.21
|-
| RTP STL
|align="right"| 2.01
|-
|}

== Configuration ==

The only configuration parameter for the RTP decoder is the '''delay''' in milliseconds.

The delay parameter is the desired processing delay of the decoder (between the network input and the audio output). Please note that the end-to-end delay between the encoder and the decoder might be (significantly) different to the value configured.

In an ideal case the delay parameter would be 0 ms, however due to device's internal buffers a small delay (depending on the hardware) is inevitable. The delay value should also cover possible temporary network hick-ups (jitter). E.g. if the network sometimes delays the packet delivery by 20ms due to a temporary load, the configured parameter should not be less than 20ms.

The maximum configurable delay is limited by the device's internal buffer (64, 32 or 16kB).

=== Recommended Settings ===
The following table lists recommended delay values for various audio formats. The value includes 2-frame jitter and is independent on hardware/software.

{| border="1" cellpadding="3" cellspacing="0"
|-
|'''Audio format'''
|'''Delay'''
|-
| MP3
| 600ms
|-
| uLaw/ALaw 8kHz mono
| 444ms
|-
| PCM 8kHz mono
| 444ms
|-
| uLaw/ALaw 12kHz mono
| 316ms
|-
| PCM 12kHz mono
| 316ms
|-
| uLaw/ALaw 24kHz mono
| 188ms
|-
| PCM 24kHz mono
| 188ms
|-
| uLaw/ALaw 32kHz mono
| 156ms
|-
| PCM 32kHz mono
| 152ms
|-
| PCM 44.1kHz stereo
| 110ms
|-
| PCM 44.1kHz mono
| 79ms
|-
| PCM 48kHz stereo
| 72ms
|-
|}

=== Maximum Settings ===
This section explains the minimum and the maximum delay values for different audio formats and platforms.

The hardware is divided into two groups:
* '''Micronas (MAS) based devices:''' Annuncicom 100/155/200/1000, Exstreamer 1000
* '''VLSI based devices:''' Exstreamer 100/110/200

====MP3 CBR====
The following table shows the minimum and the maximum possible delay with MP3 constant bitrate. The maximum delay differs between the Streaming Client, which has 64kB audio buffer available, and ABCL (Annuncicom FDX, STL), which features only 32kB buffer. The minimum delay includes 100ms network jitter.

{| border="1" cellpadding="3" cellspacing="0"
|-
|'''MP3 CBR bitrate'''
|'''Min delay'''
|'''Max delay (SC)'''
|'''Max delay (ABCL)'''
|-
| 320kbps
| 150ms
| 1,588ms
| 769ms
|-
| 256kbps
| 163ms
| 2,011ms
| 987ms
|-
| 192kbps
| 183ms
| 2,741ms
| 1,349ms
|-
| 160kbps
| 200ms
| 3,277ms
| 1,638ms
|-
| 128kbps
| 225ms
| 4,121ms
| 2,073ms
|-
| 64kbps
| 350ms
| 8,342ms
| 4,246ms
|-
| 32kbps
| 600ms
| 16,784ms
| 8,592ms
|-
|}

====MP3 VBR and ABR====
Variable or average bitrate the minimum and delay depends on the bitrate variation interval. The minimum delay is taken from the CBR table for the low end of the interval, whereas the maximum delay is the CBR value for the high end of the interval.

Please note that most MP3 encoders use the whole bitrate range starting from the lowest bitrate 32kbps. E.g. VBR 128kbps varies from 32 to 128kbps

{| border="1" cellpadding="3" cellspacing="0"
|-
|'''MP3 Format'''
|'''Min delay'''
|'''Max delay (SC)'''
|'''Max delay (ABCL)'''
|-
| 32-320kbps
| 600ms
| 1,588ms
| 769ms
|-
| 32-256kbps
| 600ms
| 2,011ms
| 987ms
|-
| 32-192kbps
| 600ms
| 2,741ms
| 1,349ms
|-
| 32-160kbps
| 600ms
| 3,277ms
| 1,638ms
|-
| 32-128kbps
| 600ms
| 4,121ms
| 2,073ms
|-
| 32-64kbps
| 600ms
| 8,342ms
| 4,246ms
|-
|}

====PCM====
In uncompressed audio (PCM, uLaw or ALaw) the minimum and maximum delay depend on the bit rate and on the hardware.

The following table lists minimum and maximum settings for all standard RTP audio formats:
{| border="1" cellpadding="3" cellspacing="0"
|-
|'''Format'''
|'''Min delay MAS'''
|'''Min delay VLSI'''
|'''Max delay (SC)'''
|'''Max delay (ABCL)'''
|'''Max delay (ABCL full duplex)'''
|-
| uLaw 8kHz mono 
ALaw 8kHz mono
| 80ms
| 424ms
| 8171ms
| 4075ms
| 2027ms
|-
| PCM 8kHz mono
| 60ms
| 424ms
| 4075ms
| 2027ms
| 1003ms
|-
| uLaw 12kHz mono 
ALaw 12kHz mono
| 67ms
| 296ms
| 5441ms
| 2710ms
| 1345ms
|-
| PCM 12kHz mono
| 54ms
| 296ms
| 2710ms
| 1345ms
| 662ms
|-
| uLaw 24kHz mono 
ALaw 24kHz mono
| 54ms
| 168ms
| 2710ms
| 1345ms
| 662ms
|-
| PCM 24kHz mono
| 47ms
| 168ms
| 1345ms
| 662ms
| 321ms
|-
| uLaw 32kHz mono 
ALaw 32kHz mono
| 50ms
| 136ms
| 2027ms
| 1003ms
| 491ms
|-
| PCM 32kHz mono
| 43ms
| 134ms
| 1005ms
| 493ms
| 237ms
|-
| PCM 44.1kHz stereo
| 31ms
| 97ms
| 729ms
| 358ms
| 172ms
|-
| PCM 44.1kHz mono
| 16ms
| 72ms
| 364ms
| 179ms
| 86ms
|-
| PCM 48kHz stereo
| 15ms
| 66ms
| 335ms
| 164ms
| 79ms
|-
|}

== Multiple Device Synchronisation ==
Multiple devices receiving the same RTP stream can be configured to play in sync by entering the same delay parameter.

Barix recommends to use broadcast or multicast together with synchronisation, otherwise a small inaccuracy (few milliseconds) might be caused by the network delivery to different locations.

== Deliberate Delays ==
In some applications it is desired to artificially delay the audio. E.g. in a tunnel to eliminate the delay caused by the distance between the devices.

An artificial delay can be introduced by configuring the devices to different delay values. E.g. 100ms, 120ms, 140ms, 160ms, etc.

RTP Buffering - Frame Based Buffering

2010-06-24T09:36:40Z

Brain: /* Recommended Settings */

== Introduction ==
In Song module version 8 a new RTP buffering method called '''frame based buffering''' was introduced.
The algorithm calculates the audio buffer level in milliseconds rather than in bytes.

== Features ==
Frame based buffering allows:
* configurable decoding delay with one frame accuracy
* synchronisation of several decoders to the same stream (just by configuring them to the same initial delay)
* stable delay over long period of time
* automatic correction of clock difference between encoder and decoder

== Applications ==
The following applications use frame based buffering:
{| border="1" cellpadding="3" cellspacing="0"
|-
|'''Application Name'''
|'''Version'''
|-
| Streaming Client
|align="right"| 2.17
|-
| Annuncicom Full Duplex
|align="right"| 0.21
|-
| RTP STL
|align="right"| 2.01
|-
|}

== Configuration ==

The only configuration parameter for the RTP decoder is the '''delay''' in milliseconds.

The delay parameter is the desired processing delay of the decoder (between the network input and the audio output). Please note that the end-to-end delay between the encoder and the decoder might be (significantly) different to the value configured.

In an ideal case the delay parameter would be 0 ms, however due to device's internal buffers a small delay (depending on the hardware) is inevitable. The delay value should also cover possible temporary network hick-ups (jitter). E.g. if the network sometimes delays the packet delivery by 20ms due to a temporary load, the configured parameter should not be less than 20ms.

The maximum configurable delay is limited by the device's internal buffer (64, 32 or 16kB).

=== Recommended Settings ===
The following table lists recommended delay values for various audio formats:

{| border="1" cellpadding="3" cellspacing="0"
|-
|'''Audio format'''
|'''Delay'''
|-
| MP3
| 600ms
|-
| uLaw/ALaw 8kHz mono
| 424ms
|-
| PCM 8kHz mono
| 424ms
|-
| uLaw/ALaw 12kHz mono
| 296ms
|-
| PCM 12kHz mono
| 296ms
|-
| uLaw/ALaw 24kHz mono
| 168ms
|-
| PCM 24kHz mono
| 168ms
|-
| uLaw/ALaw 32kHz mono
| 136ms
|-
| PCM 32kHz mono
| 134ms
|-
| PCM 44.1kHz stereo
| 97ms
|-
| PCM 44.1kHz mono
| 72ms
|-
| PCM 48kHz stereo
| 66ms
|-
|}

=== Maximum Settings ===
This section explains the minimum and the maximum delay values for different audio formats and platforms.

The hardware is divided into two groups:
* '''Micronas (MAS) based devices:''' Annuncicom 100/155/200/1000, Exstreamer 1000
* '''VLSI based devices:''' Exstreamer 100/110/200

====MP3 CBR====
The following table shows the minimum and the maximum possible delay with MP3 constant bitrate. The maximum delay differs between the Streaming Client, which has 64kB audio buffer available, and ABCL (Annuncicom FDX, STL), which features only 32kB buffer. The minimum delay includes 100ms network jitter.

{| border="1" cellpadding="3" cellspacing="0"
|-
|'''MP3 CBR bitrate'''
|'''Min delay'''
|'''Max delay (SC)'''
|'''Max delay (ABCL)'''
|-
| 320kbps
| 150ms
| 1,588ms
| 769ms
|-
| 256kbps
| 163ms
| 2,011ms
| 987ms
|-
| 192kbps
| 183ms
| 2,741ms
| 1,349ms
|-
| 160kbps
| 200ms
| 3,277ms
| 1,638ms
|-
| 128kbps
| 225ms
| 4,121ms
| 2,073ms
|-
| 64kbps
| 350ms
| 8,342ms
| 4,246ms
|-
| 32kbps
| 600ms
| 16,784ms
| 8,592ms
|-
|}

====MP3 VBR and ABR====
Variable or average bitrate the minimum and delay depends on the bitrate variation interval. The minimum delay is taken from the CBR table for the low end of the interval, whereas the maximum delay is the CBR value for the high end of the interval.

Please note that most MP3 encoders use the whole bitrate range starting from the lowest bitrate 32kbps. E.g. VBR 128kbps varies from 32 to 128kbps

{| border="1" cellpadding="3" cellspacing="0"
|-
|'''MP3 Format'''
|'''Min delay'''
|'''Max delay (SC)'''
|'''Max delay (ABCL)'''
|-
| 32-320kbps
| 600ms
| 1,588ms
| 769ms
|-
| 32-256kbps
| 600ms
| 2,011ms
| 987ms
|-
| 32-192kbps
| 600ms
| 2,741ms
| 1,349ms
|-
| 32-160kbps
| 600ms
| 3,277ms
| 1,638ms
|-
| 32-128kbps
| 600ms
| 4,121ms
| 2,073ms
|-
| 32-64kbps
| 600ms
| 8,342ms
| 4,246ms
|-
|}

====PCM====
In uncompressed audio (PCM, uLaw or ALaw) the minimum and maximum delay depend on the bit rate and on the hardware.

The following table lists minimum and maximum settings for all standard RTP audio formats:
{| border="1" cellpadding="3" cellspacing="0"
|-
|'''Format'''
|'''Min delay MAS'''
|'''Min delay VLSI'''
|'''Max delay (SC)'''
|'''Max delay (ABCL)'''
|'''Max delay (ABCL full duplex)'''
|-
| uLaw 8kHz mono 
ALaw 8kHz mono
| 80ms
| 424ms
| 8171ms
| 4075ms
| 2027ms
|-
| PCM 8kHz mono
| 60ms
| 424ms
| 4075ms
| 2027ms
| 1003ms
|-
| uLaw 12kHz mono 
ALaw 12kHz mono
| 67ms
| 296ms
| 5441ms
| 2710ms
| 1345ms
|-
| PCM 12kHz mono
| 54ms
| 296ms
| 2710ms
| 1345ms
| 662ms
|-
| uLaw 24kHz mono 
ALaw 24kHz mono
| 54ms
| 168ms
| 2710ms
| 1345ms
| 662ms
|-
| PCM 24kHz mono
| 47ms
| 168ms
| 1345ms
| 662ms
| 321ms
|-
| uLaw 32kHz mono 
ALaw 32kHz mono
| 50ms
| 136ms
| 2027ms
| 1003ms
| 491ms
|-
| PCM 32kHz mono
| 43ms
| 134ms
| 1005ms
| 493ms
| 237ms
|-
| PCM 44.1kHz stereo
| 31ms
| 97ms
| 729ms
| 358ms
| 172ms
|-
| PCM 44.1kHz mono
| 16ms
| 72ms
| 364ms
| 179ms
| 86ms
|-
| PCM 48kHz stereo
| 15ms
| 66ms
| 335ms
| 164ms
| 79ms
|-
|}

== Multiple Device Synchronisation ==
Multiple devices receiving the same RTP stream can be configured to play in sync by entering the same delay parameter.

Barix recommends to use broadcast or multicast together with synchronisation, otherwise a small inaccuracy (few milliseconds) might be caused by the network delivery to different locations.

== Deliberate Delays ==
In some applications it is desired to artificially delay the audio. E.g. in a tunnel to eliminate the delay caused by the distance between the devices.

An artificial delay can be introduced by configuring the devices to different delay values. E.g. 100ms, 120ms, 140ms, 160ms, etc.

RTP Buffering - Frame Based Buffering

2010-06-24T09:35:44Z

Brain: /* Configuration */

== Introduction ==
In Song module version 8 a new RTP buffering method called '''frame based buffering''' was introduced.
The algorithm calculates the audio buffer level in milliseconds rather than in bytes.

== Features ==
Frame based buffering allows:
* configurable decoding delay with one frame accuracy
* synchronisation of several decoders to the same stream (just by configuring them to the same initial delay)
* stable delay over long period of time
* automatic correction of clock difference between encoder and decoder

== Applications ==
The following applications use frame based buffering:
{| border="1" cellpadding="3" cellspacing="0"
|-
|'''Application Name'''
|'''Version'''
|-
| Streaming Client
|align="right"| 2.17
|-
| Annuncicom Full Duplex
|align="right"| 0.21
|-
| RTP STL
|align="right"| 2.01
|-
|}

== Configuration ==

The only configuration parameter for the RTP decoder is the '''delay''' in milliseconds.

The delay parameter is the desired processing delay of the decoder (between the network input and the audio output). Please note that the end-to-end delay between the encoder and the decoder might be (significantly) different to the value configured.

In an ideal case the delay parameter would be 0 ms, however due to device's internal buffers a small delay (depending on the hardware) is inevitable. The delay value should also cover possible temporary network hick-ups (jitter). E.g. if the network sometimes delays the packet delivery by 20ms due to a temporary load, the configured parameter should not be less than 20ms.

The maximum configurable delay is limited by the device's internal buffer (64, 32 or 16kB).

=== Recommended Settings ===
The following table lists recommended delay values for various audio formats:

{| border="1" cellpadding="3" cellspacing="0"
|-
|'''Audio format'''
|'''Delay'''
|-
| MP3
| 600ms
|-
| uLaw 8kHz mono 
ALaw 8kHz mono
| 424ms
|-
| PCM 8kHz mono
| 424ms
|-
| uLaw 12kHz mono 
ALaw 12kHz mono
| 296ms
|-
| PCM 12kHz mono
| 296ms
|-
| uLaw 24kHz mono 
ALaw 24kHz mono
| 168ms
|-
| PCM 24kHz mono
| 168ms
|-
| uLaw 32kHz mono 
ALaw 32kHz mono
| 136ms
|-
| PCM 32kHz mono
| 134ms
|-
| PCM 44.1kHz stereo
| 97ms
|-
| PCM 44.1kHz mono
| 72ms
|-
| PCM 48kHz stereo
| 66ms
|-
|}

=== Maximum Settings ===
This section explains the minimum and the maximum delay values for different audio formats and platforms.

The hardware is divided into two groups:
* '''Micronas (MAS) based devices:''' Annuncicom 100/155/200/1000, Exstreamer 1000
* '''VLSI based devices:''' Exstreamer 100/110/200

====MP3 CBR====
The following table shows the minimum and the maximum possible delay with MP3 constant bitrate. The maximum delay differs between the Streaming Client, which has 64kB audio buffer available, and ABCL (Annuncicom FDX, STL), which features only 32kB buffer. The minimum delay includes 100ms network jitter.

{| border="1" cellpadding="3" cellspacing="0"
|-
|'''MP3 CBR bitrate'''
|'''Min delay'''
|'''Max delay (SC)'''
|'''Max delay (ABCL)'''
|-
| 320kbps
| 150ms
| 1,588ms
| 769ms
|-
| 256kbps
| 163ms
| 2,011ms
| 987ms
|-
| 192kbps
| 183ms
| 2,741ms
| 1,349ms
|-
| 160kbps
| 200ms
| 3,277ms
| 1,638ms
|-
| 128kbps
| 225ms
| 4,121ms
| 2,073ms
|-
| 64kbps
| 350ms
| 8,342ms
| 4,246ms
|-
| 32kbps
| 600ms
| 16,784ms
| 8,592ms
|-
|}

====MP3 VBR and ABR====
Variable or average bitrate the minimum and delay depends on the bitrate variation interval. The minimum delay is taken from the CBR table for the low end of the interval, whereas the maximum delay is the CBR value for the high end of the interval.

Please note that most MP3 encoders use the whole bitrate range starting from the lowest bitrate 32kbps. E.g. VBR 128kbps varies from 32 to 128kbps

{| border="1" cellpadding="3" cellspacing="0"
|-
|'''MP3 Format'''
|'''Min delay'''
|'''Max delay (SC)'''
|'''Max delay (ABCL)'''
|-
| 32-320kbps
| 600ms
| 1,588ms
| 769ms
|-
| 32-256kbps
| 600ms
| 2,011ms
| 987ms
|-
| 32-192kbps
| 600ms
| 2,741ms
| 1,349ms
|-
| 32-160kbps
| 600ms
| 3,277ms
| 1,638ms
|-
| 32-128kbps
| 600ms
| 4,121ms
| 2,073ms
|-
| 32-64kbps
| 600ms
| 8,342ms
| 4,246ms
|-
|}

====PCM====
In uncompressed audio (PCM, uLaw or ALaw) the minimum and maximum delay depend on the bit rate and on the hardware.

The following table lists minimum and maximum settings for all standard RTP audio formats:
{| border="1" cellpadding="3" cellspacing="0"
|-
|'''Format'''
|'''Min delay MAS'''
|'''Min delay VLSI'''
|'''Max delay (SC)'''
|'''Max delay (ABCL)'''
|'''Max delay (ABCL full duplex)'''
|-
| uLaw 8kHz mono 
ALaw 8kHz mono
| 80ms
| 424ms
| 8171ms
| 4075ms
| 2027ms
|-
| PCM 8kHz mono
| 60ms
| 424ms
| 4075ms
| 2027ms
| 1003ms
|-
| uLaw 12kHz mono 
ALaw 12kHz mono
| 67ms
| 296ms
| 5441ms
| 2710ms
| 1345ms
|-
| PCM 12kHz mono
| 54ms
| 296ms
| 2710ms
| 1345ms
| 662ms
|-
| uLaw 24kHz mono 
ALaw 24kHz mono
| 54ms
| 168ms
| 2710ms
| 1345ms
| 662ms
|-
| PCM 24kHz mono
| 47ms
| 168ms
| 1345ms
| 662ms
| 321ms
|-
| uLaw 32kHz mono 
ALaw 32kHz mono
| 50ms
| 136ms
| 2027ms
| 1003ms
| 491ms
|-
| PCM 32kHz mono
| 43ms
| 134ms
| 1005ms
| 493ms
| 237ms
|-
| PCM 44.1kHz stereo
| 31ms
| 97ms
| 729ms
| 358ms
| 172ms
|-
| PCM 44.1kHz mono
| 16ms
| 72ms
| 364ms
| 179ms
| 86ms
|-
| PCM 48kHz stereo
| 15ms
| 66ms
| 335ms
| 164ms
| 79ms
|-
|}

== Multiple Device Synchronisation ==
Multiple devices receiving the same RTP stream can be configured to play in sync by entering the same delay parameter.

Barix recommends to use broadcast or multicast together with synchronisation, otherwise a small inaccuracy (few milliseconds) might be caused by the network delivery to different locations.

== Deliberate Delays ==
In some applications it is desired to artificially delay the audio. E.g. in a tunnel to eliminate the delay caused by the distance between the devices.

An artificial delay can be introduced by configuring the devices to different delay values. E.g. 100ms, 120ms, 140ms, 160ms, etc.

RTP Buffering - Frame Based Buffering

2010-06-24T09:30:33Z

Brain: /* Configuration */

== Introduction ==
In Song module version 8 a new RTP buffering method called '''frame based buffering''' was introduced.
The algorithm calculates the audio buffer level in milliseconds rather than in bytes.

== Features ==
Frame based buffering allows:
* configurable decoding delay with one frame accuracy
* synchronisation of several decoders to the same stream (just by configuring them to the same initial delay)
* stable delay over long period of time
* automatic correction of clock difference between encoder and decoder

== Applications ==
The following applications use frame based buffering:
{| border="1" cellpadding="3" cellspacing="0"
|-
|'''Application Name'''
|'''Version'''
|-
| Streaming Client
|align="right"| 2.17
|-
| Annuncicom Full Duplex
|align="right"| 0.21
|-
| RTP STL
|align="right"| 2.01
|-
|}

== Configuration ==

The only configuration parameter for the RTP decoder is the '''delay''' in milliseconds.

The delay parameter is the desired processing delay of the decoder (between the network input and the audio output). Please note that the end-to-end delay between the encoder and the decoder might be (significantly) different to the value configured.

In an ideal case the delay parameter would be 0 ms, however due to device's internal buffers a small delay (depending on the hardware) is inevitable. The delay value should also cover possible temporary network hick-ups (jitter). E.g. if the network might sometimes delay the packet delivery by 20ms due to a temporary load, the configured parameter should not be less than 20ms.

The maximum configurable delay is limited by the device's internal buffer (64, 32 or 16kB).

The following sections show recommended delay values for various audio formats.
=== Recommended Settings ===
{| border="1" cellpadding="3" cellspacing="0"
|-
|'''Audio format'''
|'''Delay'''
|-
| MP3
| 600ms
|-
| uLaw 8kHz mono 
ALaw 8kHz mono
| 424ms
|-
| PCM 8kHz mono
| 424ms
|-
| uLaw 12kHz mono 
ALaw 12kHz mono
| 296ms
|-
| PCM 12kHz mono
| 296ms
|-
| uLaw 24kHz mono 
ALaw 24kHz mono
| 168ms
|-
| PCM 24kHz mono
| 168ms
|-
| uLaw 32kHz mono 
ALaw 32kHz mono
| 136ms
|-
| PCM 32kHz mono
| 134ms
|-
| PCM 44.1kHz stereo
| 97ms
|-
| PCM 44.1kHz mono
| 72ms
|-
| PCM 48kHz stereo
| 66ms
|-
|}

=== Maximum Settings ===
====MP3 CBR====
The following table shows the minimum and the maximum possible delay with MP3 constant bitrate. The maximum delay differs between the Streaming Client, which has 64kB audio buffer available, and ABCL (Annuncicom FDX, STL), which features only 32kB buffer. The minimum delay includes 100ms network jitter.

{| border="1" cellpadding="3" cellspacing="0"
|-
|'''MP3 CBR bitrate'''
|'''Min delay'''
|'''Max delay (SC)'''
|'''Max delay (ABCL)'''
|-
| 320kbps
| 150ms
| 1,588ms
| 769ms
|-
| 256kbps
| 163ms
| 2,011ms
| 987ms
|-
| 192kbps
| 183ms
| 2,741ms
| 1,349ms
|-
| 160kbps
| 200ms
| 3,277ms
| 1,638ms
|-
| 128kbps
| 225ms
| 4,121ms
| 2,073ms
|-
| 64kbps
| 350ms
| 8,342ms
| 4,246ms
|-
| 32kbps
| 600ms
| 16,784ms
| 8,592ms
|-
|}

====MP3 VBR and ABR====
Variable or average bitrate the minimum and delay depends on the bitrate variation interval. The minimum delay is taken from the CBR table for the low end of the interval, whereas the maximum delay is the CBR value for the high end of the interval.

Please note that most MP3 encoders use the whole bitrate range starting from the lowest bitrate 32kbps. E.g. VBR 128kbps varies from 32 to 128kbps

{| border="1" cellpadding="3" cellspacing="0"
|-
|'''MP3 Format'''
|'''Min delay'''
|'''Max delay (SC)'''
|'''Max delay (ABCL)'''
|-
| 32-320kbps
| 600ms
| 1,588ms
| 769ms
|-
| 32-256kbps
| 600ms
| 2,011ms
| 987ms
|-
| 32-192kbps
| 600ms
| 2,741ms
| 1,349ms
|-
| 32-160kbps
| 600ms
| 3,277ms
| 1,638ms
|-
| 32-128kbps
| 600ms
| 4,121ms
| 2,073ms
|-
| 32-64kbps
| 600ms
| 8,342ms
| 4,246ms
|-
|}

====PCM====
In uncompressed audio (PCM, uLaw or ALaw) the minimum and maximum delay depend on the bit rate and on the hardware.

The following table lists minimum and maximum settings for all standard RTP audio formats:
{| border="1" cellpadding="3" cellspacing="0"
|-
|'''Format'''
|'''Min delay MAS'''
|'''Min delay VLSI'''
|'''Max delay (SC)'''
|'''Max delay (ABCL)'''
|'''Max delay (ABCL full duplex)'''
|-
| uLaw 8kHz mono 
ALaw 8kHz mono
| 80ms
| 424ms
| 8171ms
| 4075ms
| 2027ms
|-
| PCM 8kHz mono
| 60ms
| 424ms
| 4075ms
| 2027ms
| 1003ms
|-
| uLaw 12kHz mono 
ALaw 12kHz mono
| 67ms
| 296ms
| 5441ms
| 2710ms
| 1345ms
|-
| PCM 12kHz mono
| 54ms
| 296ms
| 2710ms
| 1345ms
| 662ms
|-
| uLaw 24kHz mono 
ALaw 24kHz mono
| 54ms
| 168ms
| 2710ms
| 1345ms
| 662ms
|-
| PCM 24kHz mono
| 47ms
| 168ms
| 1345ms
| 662ms
| 321ms
|-
| uLaw 32kHz mono 
ALaw 32kHz mono
| 50ms
| 136ms
| 2027ms
| 1003ms
| 491ms
|-
| PCM 32kHz mono
| 43ms
| 134ms
| 1005ms
| 493ms
| 237ms
|-
| PCM 44.1kHz stereo
| 31ms
| 97ms
| 729ms
| 358ms
| 172ms
|-
| PCM 44.1kHz mono
| 16ms
| 72ms
| 364ms
| 179ms
| 86ms
|-
| PCM 48kHz stereo
| 15ms
| 66ms
| 335ms
| 164ms
| 79ms
|-
|}

== Multiple Device Synchronisation ==
Multiple devices receiving the same RTP stream can be configured to play in sync by entering the same delay parameter.

Barix recommends to use broadcast or multicast together with synchronisation, otherwise a small inaccuracy (few milliseconds) might be caused by the network delivery to different locations.

== Deliberate Delays ==
In some applications it is desired to artificially delay the audio. E.g. in a tunnel to eliminate the delay caused by the distance between the devices.

An artificial delay can be introduced by configuring the devices to different delay values. E.g. 100ms, 120ms, 140ms, 160ms, etc.

RTP Buffering - Frame Based Buffering

2010-06-24T09:25:15Z

Brain: /* PCM */

== Introduction ==
In Song module version 8 a new RTP buffering method called '''frame based buffering''' was introduced.
The algorithm calculates the audio buffer level in milliseconds rather than in bytes.

== Features ==
Frame based buffering allows:
* configurable decoding delay with one frame accuracy
* synchronisation of several decoders to the same stream (just by configuring them to the same initial delay)
* stable delay over long period of time
* automatic correction of clock difference between encoder and decoder

== Applications ==
The following applications use frame based buffering:
{| border="1" cellpadding="3" cellspacing="0"
|-
|'''Application Name'''
|'''Version'''
|-
| Streaming Client
|align="right"| 2.17
|-
| Annuncicom Full Duplex
|align="right"| 0.21
|-
| RTP STL
|align="right"| 2.01
|-
|}

== Configuration ==

The only configuration parameter for the RTP decoder is the '''delay''' in milliseconds.

The delay parameter is the desired processing delay of the decoder (between the network input and the audio output). Please note that the end-to-end delay between the encoder and the decoder might be (significantly) different to the value configured.

In an ideal case the delay parameter would be 0 ms, however due to device's internal buffers a small delay (depending on the hardware) is inevitable. The delay value should also cover possible temporary network hick-ups (jitter). E.g. if the network might sometimes delay the packet delivery by 20ms due to a temporary load, the configured parameter should not be less than 20ms.

The maximum configurable delay is limited by the device's internal buffer (64, 32 or 16kB).

The following sections show recommended delay values for various audio formats.
=== Recommended Settings ===
====MP3 CBR====
The following table shows the minimum and the maximum possible delay with MP3 constant bitrate. The maximum delay differs between the Streaming Client, which has 64kB audio buffer available, and ABCL (Annuncicom FDX, STL), which features only 32kB buffer. The minimum delay includes 100ms network jitter.

{| border="1" cellpadding="3" cellspacing="0"
|-
|'''MP3 CBR bitrate'''
|'''Min delay'''
|'''Max delay (SC)'''
|'''Max delay (ABCL)'''
|-
| 320kbps
| 150ms
| 1,588ms
| 769ms
|-
| 256kbps
| 163ms
| 2,011ms
| 987ms
|-
| 192kbps
| 183ms
| 2,741ms
| 1,349ms
|-
| 160kbps
| 200ms
| 3,277ms
| 1,638ms
|-
| 128kbps
| 225ms
| 4,121ms
| 2,073ms
|-
| 64kbps
| 350ms
| 8,342ms
| 4,246ms
|-
| 32kbps
| 600ms
| 16,784ms
| 8,592ms
|-
|}

====MP3 VBR and ABR====
Variable or average bitrate the minimum and delay depends on the bitrate variation interval. The minimum delay is taken from the CBR table for the low end of the interval, whereas the maximum delay is the CBR value for the high end of the interval.

Please note that most MP3 encoders use the whole bitrate range starting from the lowest bitrate 32kbps. E.g. VBR 128kbps varies from 32 to 128kbps

{| border="1" cellpadding="3" cellspacing="0"
|-
|'''MP3 Format'''
|'''Min delay'''
|'''Max delay (SC)'''
|'''Max delay (ABCL)'''
|-
| 32-320kbps
| 600ms
| 1,588ms
| 769ms
|-
| 32-256kbps
| 600ms
| 2,011ms
| 987ms
|-
| 32-192kbps
| 600ms
| 2,741ms
| 1,349ms
|-
| 32-160kbps
| 600ms
| 3,277ms
| 1,638ms
|-
| 32-128kbps
| 600ms
| 4,121ms
| 2,073ms
|-
| 32-64kbps
| 600ms
| 8,342ms
| 4,246ms
|-
|}

====PCM====
In uncompressed audio (PCM, uLaw or ALaw) the minimum and maximum delay depend on the bit rate and on the hardware.

The following table lists minimum and maximum settings for all standard RTP audio formats:
{| border="1" cellpadding="3" cellspacing="0"
|-
|'''Format'''
|'''Min delay MAS'''
|'''Min delay VLSI'''
|'''Max delay (SC)'''
|'''Max delay (ABCL)'''
|'''Max delay (ABCL full duplex)'''
|-
| uLaw 8kHz mono 
ALaw 8kHz mono
| 80ms
| 424ms
| 8171ms
| 4075ms
| 2027ms
|-
| PCM 8kHz mono
| 60ms
| 424ms
| 4075ms
| 2027ms
| 1003ms
|-
| uLaw 12kHz mono 
ALaw 12kHz mono
| 67ms
| 296ms
| 5441ms
| 2710ms
| 1345ms
|-
| PCM 12kHz mono
| 54ms
| 296ms
| 2710ms
| 1345ms
| 662ms
|-
| uLaw 24kHz mono 
ALaw 24kHz mono
| 54ms
| 168ms
| 2710ms
| 1345ms
| 662ms
|-
| PCM 24kHz mono
| 47ms
| 168ms
| 1345ms
| 662ms
| 321ms
|-
| uLaw 32kHz mono 
ALaw 32kHz mono
| 50ms
| 136ms
| 2027ms
| 1003ms
| 491ms
|-
| PCM 32kHz mono
| 43ms
| 134ms
| 1005ms
| 493ms
| 237ms
|-
| PCM 44.1kHz stereo
| 31ms
| 97ms
| 729ms
| 358ms
| 172ms
|-
| PCM 44.1kHz mono
| 16ms
| 72ms
| 364ms
| 179ms
| 86ms
|-
| PCM 48kHz stereo
| 15ms
| 66ms
| 335ms
| 164ms
| 79ms
|-
|}

== Multiple Device Synchronisation ==
Multiple devices receiving the same RTP stream can be configured to play in sync by entering the same delay parameter.

Barix recommends to use broadcast or multicast together with synchronisation, otherwise a small inaccuracy (few milliseconds) might be caused by the network delivery to different locations.

== Deliberate Delays ==
In some applications it is desired to artificially delay the audio. E.g. in a tunnel to eliminate the delay caused by the distance between the devices.

An artificial delay can be introduced by configuring the devices to different delay values. E.g. 100ms, 120ms, 140ms, 160ms, etc.

RTP Buffering - Frame Based Buffering

2010-06-24T09:24:32Z

Brain: /* PCM */

== Introduction ==
In Song module version 8 a new RTP buffering method called '''frame based buffering''' was introduced.
The algorithm calculates the audio buffer level in milliseconds rather than in bytes.

== Features ==
Frame based buffering allows:
* configurable decoding delay with one frame accuracy
* synchronisation of several decoders to the same stream (just by configuring them to the same initial delay)
* stable delay over long period of time
* automatic correction of clock difference between encoder and decoder

== Applications ==
The following applications use frame based buffering:
{| border="1" cellpadding="3" cellspacing="0"
|-
|'''Application Name'''
|'''Version'''
|-
| Streaming Client
|align="right"| 2.17
|-
| Annuncicom Full Duplex
|align="right"| 0.21
|-
| RTP STL
|align="right"| 2.01
|-
|}

== Configuration ==

The only configuration parameter for the RTP decoder is the '''delay''' in milliseconds.

The delay parameter is the desired processing delay of the decoder (between the network input and the audio output). Please note that the end-to-end delay between the encoder and the decoder might be (significantly) different to the value configured.

In an ideal case the delay parameter would be 0 ms, however due to device's internal buffers a small delay (depending on the hardware) is inevitable. The delay value should also cover possible temporary network hick-ups (jitter). E.g. if the network might sometimes delay the packet delivery by 20ms due to a temporary load, the configured parameter should not be less than 20ms.

The maximum configurable delay is limited by the device's internal buffer (64, 32 or 16kB).

The following sections show recommended delay values for various audio formats.
=== Recommended Settings ===
====MP3 CBR====
The following table shows the minimum and the maximum possible delay with MP3 constant bitrate. The maximum delay differs between the Streaming Client, which has 64kB audio buffer available, and ABCL (Annuncicom FDX, STL), which features only 32kB buffer. The minimum delay includes 100ms network jitter.

{| border="1" cellpadding="3" cellspacing="0"
|-
|'''MP3 CBR bitrate'''
|'''Min delay'''
|'''Max delay (SC)'''
|'''Max delay (ABCL)'''
|-
| 320kbps
| 150ms
| 1,588ms
| 769ms
|-
| 256kbps
| 163ms
| 2,011ms
| 987ms
|-
| 192kbps
| 183ms
| 2,741ms
| 1,349ms
|-
| 160kbps
| 200ms
| 3,277ms
| 1,638ms
|-
| 128kbps
| 225ms
| 4,121ms
| 2,073ms
|-
| 64kbps
| 350ms
| 8,342ms
| 4,246ms
|-
| 32kbps
| 600ms
| 16,784ms
| 8,592ms
|-
|}

====MP3 VBR and ABR====
Variable or average bitrate the minimum and delay depends on the bitrate variation interval. The minimum delay is taken from the CBR table for the low end of the interval, whereas the maximum delay is the CBR value for the high end of the interval.

Please note that most MP3 encoders use the whole bitrate range starting from the lowest bitrate 32kbps. E.g. VBR 128kbps varies from 32 to 128kbps

{| border="1" cellpadding="3" cellspacing="0"
|-
|'''MP3 Format'''
|'''Min delay'''
|'''Max delay (SC)'''
|'''Max delay (ABCL)'''
|-
| 32-320kbps
| 600ms
| 1,588ms
| 769ms
|-
| 32-256kbps
| 600ms
| 2,011ms
| 987ms
|-
| 32-192kbps
| 600ms
| 2,741ms
| 1,349ms
|-
| 32-160kbps
| 600ms
| 3,277ms
| 1,638ms
|-
| 32-128kbps
| 600ms
| 4,121ms
| 2,073ms
|-
| 32-64kbps
| 600ms
| 8,342ms
| 4,246ms
|-
|}

====PCM====
In uncompressed audio (PCM, uLaw or ALaw) the minimum and maximum delay depend on the bit rate and on the hardware.

The following table lists minimum and maximum settings for all standard RTP audio formats:
{| border="1" cellpadding="3" cellspacing="0"
|-
|'''Format'''
|'''Min delay MAS'''
|'''Min delay VLSI'''
|'''Max delay (SC)'''
|'''Max delay (ABCL)'''
|'''Max delay (ABCL full duplex)'''
|-
| uLaw 8kHz mono 
ALaw 8kHz mono
| 80ms
| 424ms
| 8171ms
| 4075ms
| 2027ms
|-
| PCM 8kHz mono
| 60ms
| 424ms
|-
| uLaw 12kHz mono 
ALaw 12kHz mono
| 67ms
| 296ms
| 5441ms
| 2710ms
| 1345ms
|-
| PCM 12kHz mono
| 54ms
| 296ms
| 2710ms
| 1345ms
| 662ms
|-
| uLaw 24kHz mono 
ALaw 24kHz mono
| 54ms
| 168ms
| 2710ms
| 1345ms
| 662ms
|-
| PCM 24kHz mono
| 47ms
| 168ms
| 1345ms
| 662ms
| 321ms
|-
| uLaw 32kHz mono 
ALaw 32kHz mono
| 50ms
| 136ms
| 2027ms
| 1003ms
| 491ms
|-
| PCM 32kHz mono
| 43ms
| 134ms
| 1005ms
| 493ms
| 237ms
|-
| PCM 44.1kHz stereo
| 31ms
| 97ms
| 729ms
| 358ms
| 172ms
|-
| PCM 44.1kHz mono
| 16ms
| 72ms
| 364ms
| 179ms
| 86ms
|-
| PCM 48kHz stereo
| 15ms
| 66ms
| 335ms
| 164ms
| 79ms
|-
|}

== Multiple Device Synchronisation ==
Multiple devices receiving the same RTP stream can be configured to play in sync by entering the same delay parameter.

Barix recommends to use broadcast or multicast together with synchronisation, otherwise a small inaccuracy (few milliseconds) might be caused by the network delivery to different locations.

== Deliberate Delays ==
In some applications it is desired to artificially delay the audio. E.g. in a tunnel to eliminate the delay caused by the distance between the devices.

An artificial delay can be introduced by configuring the devices to different delay values. E.g. 100ms, 120ms, 140ms, 160ms, etc.

RTP Buffering - Frame Based Buffering

2010-06-24T09:09:52Z

Brain: /* PCM */

== Introduction ==
In Song module version 8 a new RTP buffering method called '''frame based buffering''' was introduced.
The algorithm calculates the audio buffer level in milliseconds rather than in bytes.

== Features ==
Frame based buffering allows:
* configurable decoding delay with one frame accuracy
* synchronisation of several decoders to the same stream (just by configuring them to the same initial delay)
* stable delay over long period of time
* automatic correction of clock difference between encoder and decoder

== Applications ==
The following applications use frame based buffering:
{| border="1" cellpadding="3" cellspacing="0"
|-
|'''Application Name'''
|'''Version'''
|-
| Streaming Client
|align="right"| 2.17
|-
| Annuncicom Full Duplex
|align="right"| 0.21
|-
| RTP STL
|align="right"| 2.01
|-
|}

== Configuration ==

The only configuration parameter for the RTP decoder is the '''delay''' in milliseconds.

The delay parameter is the desired processing delay of the decoder (between the network input and the audio output). Please note that the end-to-end delay between the encoder and the decoder might be (significantly) different to the value configured.

In an ideal case the delay parameter would be 0 ms, however due to device's internal buffers a small delay (depending on the hardware) is inevitable. The delay value should also cover possible temporary network hick-ups (jitter). E.g. if the network might sometimes delay the packet delivery by 20ms due to a temporary load, the configured parameter should not be less than 20ms.

The maximum configurable delay is limited by the device's internal buffer (64, 32 or 16kB).

The following sections show recommended delay values for various audio formats.
=== Recommended Settings ===
====MP3 CBR====
The following table shows the minimum and the maximum possible delay with MP3 constant bitrate. The maximum delay differs between the Streaming Client, which has 64kB audio buffer available, and ABCL (Annuncicom FDX, STL), which features only 32kB buffer. The minimum delay includes 100ms network jitter.

{| border="1" cellpadding="3" cellspacing="0"
|-
|'''MP3 CBR bitrate'''
|'''Min delay'''
|'''Max delay (SC)'''
|'''Max delay (ABCL)'''
|-
| 320kbps
| 150ms
| 1,588ms
| 769ms
|-
| 256kbps
| 163ms
| 2,011ms
| 987ms
|-
| 192kbps
| 183ms
| 2,741ms
| 1,349ms
|-
| 160kbps
| 200ms
| 3,277ms
| 1,638ms
|-
| 128kbps
| 225ms
| 4,121ms
| 2,073ms
|-
| 64kbps
| 350ms
| 8,342ms
| 4,246ms
|-
| 32kbps
| 600ms
| 16,784ms
| 8,592ms
|-
|}

====MP3 VBR and ABR====
Variable or average bitrate the minimum and delay depends on the bitrate variation interval. The minimum delay is taken from the CBR table for the low end of the interval, whereas the maximum delay is the CBR value for the high end of the interval.

Please note that most MP3 encoders use the whole bitrate range starting from the lowest bitrate 32kbps. E.g. VBR 128kbps varies from 32 to 128kbps

{| border="1" cellpadding="3" cellspacing="0"
|-
|'''MP3 Format'''
|'''Min delay'''
|'''Max delay (SC)'''
|'''Max delay (ABCL)'''
|-
| 32-320kbps
| 600ms
| 1,588ms
| 769ms
|-
| 32-256kbps
| 600ms
| 2,011ms
| 987ms
|-
| 32-192kbps
| 600ms
| 2,741ms
| 1,349ms
|-
| 32-160kbps
| 600ms
| 3,277ms
| 1,638ms
|-
| 32-128kbps
| 600ms
| 4,121ms
| 2,073ms
|-
| 32-64kbps
| 600ms
| 8,342ms
| 4,246ms
|-
|}

====PCM====
In uncompressed audio (PCM, uLaw or ALaw) the minimum and maximum delay depend on the bit rate and on the hardware.

The following table lists minimum and maximum settings for all standard RTP audio formats:
{| border="1" cellpadding="3" cellspacing="0"
|-
|'''Format'''
|'''Min delay VLSI'''
|'''Min delay MAS'''
|'''Max delay (SC)'''
|'''Max delay (ABCL)'''
|'''Max delay (ABCL full duplex)'''
|-
| uLaw 8kHz mono 
ALaw 8kHz mono
| 349ms
| 80ms
| 8170ms
| 4057ms
| 2027ms
|-
| PCM 8kHz mono
| 323ms
| 60ms
| 4075ms
| 2027ms
| 1003ms
|-
| uLaw 12kHz mono 
ALaw 12kHz mono
| 246ms
| 67ms
| 5441ms
| 2710ms
| 1345ms
|-
| PCM 12kHz mono
| 229ms
| 54ms
| 2710ms
| 1345ms
| 662ms
|-
| uLaw 24kHz mono 
ALaw 24kHz mono
|-
| PCM 24kHz mono
|-
| uLaw 32kHz mono 
ALaw 32kHz mono
|-
| PCM 32kHz mono
|-
| PCM 44.1kHz stereo
|-
| PCM 44.1kHz mono
|-
| PCM 48kHz stereo
|-
|-
|}

== Multiple Device Synchronisation ==
Multiple devices receiving the same RTP stream can be configured to play in sync by entering the same delay parameter.

Barix recommends to use broadcast or multicast together with synchronisation, otherwise a small inaccuracy (few milliseconds) might be caused by the network delivery to different locations.

== Deliberate Delays ==
In some applications it is desired to artificially delay the audio. E.g. in a tunnel to eliminate the delay caused by the distance between the devices.

An artificial delay can be introduced by configuring the devices to different delay values. E.g. 100ms, 120ms, 140ms, 160ms, etc.

RTP Buffering - Frame Based Buffering

2010-06-22T16:21:54Z

Brain: /* Configuration */

== Introduction ==
In Song module version 8 a new RTP buffering method called '''frame based buffering''' was introduced.
The algorithm calculates the audio buffer level in milliseconds rather than in bytes.

== Features ==
Frame based buffering allows:
* configurable decoding delay with one frame accuracy
* synchronisation of several decoders to the same stream (just by configuring them to the same initial delay)
* stable delay over long period of time
* automatic correction of clock difference between encoder and decoder

== Applications ==
The following applications use frame based buffering:
{| border="1" cellpadding="3" cellspacing="0"
|-
|'''Application Name'''
|'''Version'''
|-
| Streaming Client
|align="right"| 2.17
|-
| Annuncicom Full Duplex
|align="right"| 0.21
|-
| RTP STL
|align="right"| 2.01
|-
|}

== Configuration ==

The only configuration parameter for the RTP decoder is the '''delay''' in milliseconds.

The delay parameter is the desired processing delay of the decoder (between the network input and the audio output). Please note that the end-to-end delay between the encoder and the decoder might be (significantly) different to the value configured.

In an ideal case the delay parameter would be 0 ms, however due to device's internal buffers a small delay (depending on the hardware) is inevitable. The delay value should also cover possible temporary network hick-ups (jitter). E.g. if the network might sometimes delay the packet delivery by 20ms due to a temporary load, the configured parameter should not be less than 20ms.

The maximum configurable delay is limited by the device's internal buffer (64, 32 or 16kB).

The following sections show recommended delay values for various audio formats.
=== Recommended Settings ===
====MP3 CBR====
The following table shows the minimum and the maximum possible delay with MP3 constant bitrate. The maximum delay differs between the Streaming Client, which has 64kB audio buffer available, and ABCL (Annuncicom FDX, STL), which features only 32kB buffer. The minimum delay includes 100ms network jitter.

{| border="1" cellpadding="3" cellspacing="0"
|-
|'''MP3 CBR bitrate'''
|'''Min delay'''
|'''Max delay (SC)'''
|'''Max delay (ABCL)'''
|-
| 320kbps
| 150ms
| 1,588ms
| 769ms
|-
| 256kbps
| 163ms
| 2,011ms
| 987ms
|-
| 192kbps
| 183ms
| 2,741ms
| 1,349ms
|-
| 160kbps
| 200ms
| 3,277ms
| 1,638ms
|-
| 128kbps
| 225ms
| 4,121ms
| 2,073ms
|-
| 64kbps
| 350ms
| 8,342ms
| 4,246ms
|-
| 32kbps
| 600ms
| 16,784ms
| 8,592ms
|-
|}

====MP3 VBR and ABR====
Variable or average bitrate the minimum and delay depends on the bitrate variation interval. The minimum delay is taken from the CBR table for the low end of the interval, whereas the maximum delay is the CBR value for the high end of the interval.

Please note that most MP3 encoders use the whole bitrate range starting from the lowest bitrate 32kbps. E.g. VBR 128kbps varies from 32 to 128kbps

{| border="1" cellpadding="3" cellspacing="0"
|-
|'''MP3 Format'''
|'''Min delay'''
|'''Max delay (SC)'''
|'''Max delay (ABCL)'''
|-
| 32-320kbps
| 600ms
| 1,588ms
| 769ms
|-
| 32-256kbps
| 600ms
| 2,011ms
| 987ms
|-
| 32-192kbps
| 600ms
| 2,741ms
| 1,349ms
|-
| 32-160kbps
| 600ms
| 3,277ms
| 1,638ms
|-
| 32-128kbps
| 600ms
| 4,121ms
| 2,073ms
|-
| 32-64kbps
| 600ms
| 8,342ms
| 4,246ms
|-
|}

====PCM====
In uncompressed audio (PCM, uLaw or ALaw) the minimum and maximum delay depend on the bit rate and on the hardware.

The following table lists minimum and maximum settings for all standard RTP audio formats:
{| border="1" cellpadding="3" cellspacing="0"
|-
|'''Format'''
|'''Min delay VLSI'''
|'''Min delay MAS'''
|'''Max delay (SC)'''
|'''Max delay (ABCL)'''
|-
| uLaw 8kHz mono 
ALaw 8kHz mono
|-
| PCM 8kHz mono
|-
| uLaw 12kHz mono 
ALaw 12kHz mono
|-
| PCM 12kHz mono
|-
| uLaw 24kHz mono 
ALaw 24kHz mono
|-
| PCM 24kHz mono
|-
| uLaw 32kHz mono 
ALaw 32kHz mono
|-
| PCM 32kHz mono
|-
| PCM 44.1kHz stereo
|-
| PCM 44.1kHz mono
|-
| PCM 48kHz stereo
|-
|-
|}

== Multiple Device Synchronisation ==
Multiple devices receiving the same RTP stream can be configured to play in sync by entering the same delay parameter.

Barix recommends to use broadcast or multicast together with synchronisation, otherwise a small inaccuracy (few milliseconds) might be caused by the network delivery to different locations.

== Deliberate Delays ==
In some applications it is desired to artificially delay the audio. E.g. in a tunnel to eliminate the delay caused by the distance between the devices.

An artificial delay can be introduced by configuring the devices to different delay values. E.g. 100ms, 120ms, 140ms, 160ms, etc.

RTP Buffering - Frame Based Buffering

2010-06-22T15:45:51Z

Brain: /* Recommended Settings */

RTP Buffering - Frame Based Buffering

2010-06-22T15:35:27Z

Brain: /* Recommended Settings */

RTP Buffering - Frame Based Buffering

2010-06-22T15:33:37Z

Brain: /* MP3 */

RTP Buffering - Frame Based Buffering

2010-06-22T15:33:20Z

Brain: /* Configuration */

RTP Buffering - Frame Based Buffering

2010-06-22T15:06:28Z

Brain: /* Configuration */

RTP Buffering - Frame Based Buffering

2010-06-22T14:59:37Z

Brain:

RTP Buffering - Frame Based Buffering

2010-06-22T14:18:21Z

Brain:

RTP Buffering - Frame Based Buffering

2010-06-22T14:00:12Z

Brain: New page: == Introduction == In Song module version 8 a new RTP buffering method called '''frame based buffering''' was introduced. The algorithm calculates the audio buffer level in milliseconds ra...

Main Page

2010-06-22T13:27:23Z

Brain: /* 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]]

== 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]

Streaming Client howtos

2010-06-22T13:16:22Z

Brain: /* How do I configure multicast? */

== How to play Windows Media streams ==

== How to monitor devices ==

== How to configure Barimon ==

== How to use remote updates ==

== How to set the stream check period ==
See the [[Stream Switching]] page.

== How to switch streams based on a day-time ==

== How to use channels ==
See the [[Channel Selection]] howto.

== What protocol shall I use? ==

== How do I configure multicast? ==

Enter the address of the multicast stream you want to listen into the URL line. E.g.
rtp://240.1.1.2:10000/
Streaming Client will automatically register to the group to receive the stream.

== How to authenticate the Streaming Client to the server ==
See the [[Streaming Client Server Authentication]] howto.

Ethersound

2010-06-21T09:35:31Z

Brain: /* How to use a device in Ethersound mode */

== 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 from a central management software controlling as well the I/O on the device. 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]]

== How to use a device in Ethersound mode ==

Once you enter the Ethersound mode (after loading the proper software and selecting the Ethersound mode on the WEB UI) the device becomes accessible only through the Ethersound network. In Ethersound mode the WEB UI is not accessible and the device does not respond to IP.

To control the channel selection, audio and I/O use the ES-Control software, which is freely downloadable from [http://www.digigram.com/ Digigram homepage]. Please use ES-Control version 2.57 or later.

By default the volume is set to -20dB and no channel is selected. Therefore to hear audio the device must be configured at least once using ES-Control. This can be done e.g. by connecting a laptop with ES-Control to the Primary Master, discovering the network and configuring Barix devices. Once you finish the configuration, press "File->Save as power up mapping" to store the settings in the device's EEPROM. After that the managing PC is not needed any more, the configuration persists over reboot.

Ethersound

2010-06-17T14:50:58Z

Brain:

== 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 from a central management software controlling as well the I/O on the device. 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]]

== How to use a device in Ethersound mode ==

Once you enter the Ethersound mode (after loading the proper software and selecting the Ethersound mode on the WEB UI) the device becomes accessible only through the Ethersound network. In Ethersound mode the WEB UI is not accessible and the device does not respond to IP.

To control the channel selection, audio and I/O use the ES-Control software, which is freely downloadable from [http://www.digigram.com/ Digigram homepage]. Please use ES-Control version 2.57 or later.

By default the volume is set to -20dB and no channel is selected. Therefore to hear audio the device must be configured at least once using ES-Control. This can be done e.g. by connecting a laptop with ES-Control to the Primary Master, discovering the network and configuring Barix devices. Once the device is configured it stores its configuration in the EEPROM and the managing PC is not needed any more. The configuration persists over reboot.

PS16 Factory Defaults

2010-03-02T11:22:22Z

Brain:

=Factory Defaults=

Since the ABCL software version 0.26 (19.1.2010) a special key combination can be used to revert factory defaults:

* power off the unit

* hold down the two most left keys in the lower row of the PS16's keyboard (keys 1 and 2):
[[Image:Ps16_defaults_1.jpg|thumb|none|400px]]

* connect the power

* after a short moment the message "Factory defaults? Press key 16 to confirm" appears on the display:
[[Image:Ps16_defaults_2.jpg|thumb|none|400px]]

* to confirm press the upper right key (while still holding they key 1 and 2!):
[[Image:Ps16_defaults_3.jpg|thumb|none|400px]]

* release all keys
[[Image:Ps16_defaults_4.jpg|thumb|none|400px]]

* the unit reverts to factory defaults and reboots

PS16 Factory Defaults

2010-03-02T11:21:45Z

Brain: /* Factory Defaults */

=Factory Defaults=

Since the ABCL software version 0.26 (since 19.1.2010) a special key combination can be used to revert factory defaults:

* power off the unit

* hold down the two most left keys in the lower row of the PS16's keyboard (keys 1 and 2):
[[Image:Ps16_defaults_1.jpg|thumb|none|400px]]

* connect the power

* after a short moment the message "Factory defaults? Press key 16 to confirm" appears on the display:
[[Image:Ps16_defaults_2.jpg|thumb|none|400px]]

* to confirm press the upper right key (while still holding they key 1 and 2!):
[[Image:Ps16_defaults_3.jpg|thumb|none|400px]]

* release all keys
[[Image:Ps16_defaults_4.jpg|thumb|none|400px]]

* the unit reverts to factory defaults and reboots

File:Ps16 defaults 4.jpg

2010-03-02T11:06:30Z

Brain:

File:Ps16 defaults 3.jpg

2010-03-02T11:06:13Z

Brain:

File:Ps16 defaults 2.jpg

2010-03-02T11:05:51Z

Brain:

File:Ps16 defaults 1.jpg

2010-03-02T11:01:02Z

Brain:

PS16 Factory Defaults

2010-03-02T10:58:54Z

Brain: /* Factory Defaults */

=Factory Defaults=

Since the ABCL software version 0.26 (since 19.1.2010) a special key combination can be used to revert factory defaults:

# power off the unit
# hold down the two most left keys in the lower row of the PS16's keyboard (keys 1 and 2):
# connect the power
# after a short moment the message "Factory defaults? Press key 16 to confirm" appears on the display:
# to confirm press the upper right key (while still holding they key 1 and 2!):
# release all keys

PS16 Factory Defaults

2010-03-02T10:58:41Z

Brain: New page: =Factory Defaults= Since the ABCL software version 0.26 (since 19.1.2010) a special key combination can be used to revert factory defaults: # power off the unit # hold down the two most ...

=Factory Defaults=

Since the ABCL software version 0.26 (since 19.1.2010) a special key combination can be used to revert factory defaults:

# power off the unit
# hold down the two most left keys in the lower row of the PS16's keyboard (keys 1 and 2):

# connect the power
# after a short moment the message "Factory defaults? Press key 16 to confirm" appears on the display:

# to confirm press the upper right key (while still holding they key 1 and 2!):

# release all keys

PS16

2010-03-02T10:50:09Z

Brain:

The Barix Paging Station PS16 is a universal,TCP/IP connected intercom station for use in IP Intercom, Paging and VoIP applications. The PS16 directly connects to the network via a 10/100Mbps network connection, and can also be powered over the network interface (PoE, 802.3af standard). For high availability applications, a second network connection and separate power input are available.

Due to the built-in intelligence and full progammability, the station can be used as a master station for IP based intercom and paging systems, which can be built without any central servers or PCs.

The PS16 is equipped with a two-line LC display, 16 individually labelable keys with LED indicator, a professional gooseneck microphone, a speaker and a buzzer.A realtime clock (with backup battery) and flash memory for stored messages and announcements is built into the device as well. The PS16 can be extended to up to 208 keys using available key extension modules which can be attached mechanically and electrically secure.

For special applications, the PS16 can be fully programmed using the Barix ABCL language. Standard applications for use as a stored message playback device, as a Master intercom/paging station and as a SIP capable phone / intercom station are preloaded (and free of charge). Central PA/Intercom software is available from Barix free of charge, along with protocol and API documentation, enabling easy integration into proprietary solutions.

'''''NOTE : The Barix PS16 is an OEM product designed and manufactured by MS Neumann Elektronik (www.neumann-elektronik.com) using the Barix IPAM 100. The Barix PS16 is not compatible with the Neumann DS-6 system and will not function with Neumann's industrial intercom applications.'''''

[[Image:Ps16_kl.gif|frame|PS16]]

More information available in our website:
http://www.barix.com/Paging_Station_PS16/1081/

'''How to revert to factory defaults?''' : Follow this [[PS16 Factory Defaults|howto]]

'''How do I build an intercom system with PS16 ?''' : Follow this [[Barix Intercom System|howto]]

Back to [[Main Page#Products]]

Exstreamer 1000

2010-02-09T10:48:32Z

Brain: contact closures are available since v2.10

The Exstreamer 1000 combines the instream and exstream technologies into a single device. It is a versatile network device suited for a variety of high quality audio applications.
The Exstreamer 1000 can be used as an audio decoder (Exstreamer functionality), or as an audio encoder (Instreamer functionality). Audio can also be transmitted bidirectionally in a full duplex configuration (ABCL application).

[[Image:Exstreamer1000_FrontPlate_Web800.gif|200px|thumb|right]]
[[Image:Exstreamer1000_RearPlate_Web800.gif|200px|thumb|right]]

The Exstreamer 1000 features:

- Balanced I/O (DSUB9 XLR adapter cable available as an option)

- AES/EBU fully digital transmission path

- High quality A/D converter

- Contact closure interfaces (4 inputs, 4 relays)

NOTE: HW features availability is related to the specific Firmware loaded on the device

=Firmware=

The Exstreamer 1000 is a universal hardware platform and can run various Barix application firmwares. All audio application firmwares provided for download on the website support the Exstreamer 1000. Firmare packages and documentation is available free of charge from Barix.
The following standard application firmware from Barix can be used:

===Instreamer Standard FW===

http://www.barix.com/downloads/Instreamer_Family/81/

Turns the Exstreamer 1000 into a high quality audio encoder supporting MP3 compression, shoutcast/icecast source protocol, RTP broadcast/multicast and raw TCP streaming.

Contact closures are supported in the Instreamer firmware in combination with RTP since the version 3.16.

USB flash memory interface is not supported in the Instreamer firmware.

===Exstreamer Standard FW===

http://www.barix.com/downloads/Exstreamer_Family/71/

Turns the Exstreamer 1000 into a high quality audio decoder supporting MP3 compression, uncompressed playback, RTP/raw UDP/TCP stream reception, synchronous audio playback etc. Serial port tunneling for the RS-232 port is supported, and the serial port can also be used as a command interface.

Contact closures are NOT yet supported in the Exstreamer standard firmware.

USB flash memory interface is not supported in the Exstreamer firmware.

===Streaming Client FW===

http://www.barix.com/downloads/Streaming_Client_Firmware/1381/

Turns the Exstreamer 1000 into a high quality stream receiver with MP3 compression and uncompressed audio support. The Streaming Client firmware allows configuration of up to 3 URLs, with auto-fallback in case of link/server failure, use of a USB flash stick for backup audio in case of higher priority stream failures etc. All standard functionality of the Streaming Client firmware is supported.

Contact closures are supported in the Streaming Client firmware in combination with RTP since the version 2.10.

===STL application ABCL FW===

http://www.barix.com/downloads/ABCL_Applications/1911/

This ABCL-based application is intended for unidirectional, high quality, uncompresssed streaming of mono or stereo audio feeds. Contact closures are supported by this application, and sent to the receiver(s) using standard UDP (separate “channel”). The target address for the stream can be a device IP address, Multicast group or the Broadcast address. Up to 4 destinations can be independently configured for the stream.
In case of a point-to-point application, contact closures can also be sent back.

For sample rates up to 24kHz, the STL application firmware also allows full duplex audio transmission (uncompressed).

===Preloaded ABCL kit FW===

http://www.barix.com/downloads/ABCL_Kit_Firmware/21/

By selecting the specific application (drop down menu) the Exstreamer 1000 can be used as Recorder audio in MP3 and store to a USB stick or a server, as a network MP3 audio Player, as an Intercom Client, as an Intercom Master, as a Full Duplex intercom component, or even as a SIP Client for VOIP phones!

=Applications=

Different applications with different characteristics need different Firmware. The following is a list of typical applications and which software is recommended to be used:

=== STL – Studio Transmitter Link===

The Exstreamer 1000 is ideally suited to set up studio transmitter links over IP infrastructure, being it Ehternet, wireless, LAN, optical fibre or WAN connections.
RTP STL application (ABCL firmware) is supporting full-duplex application for uncompressed analog audio and half-duplex MP3 digital audio stereo streaming at up to 48kHz sample rates.
Along with the Audio, I/O (4 contact closures) can be transmitted. In the current implementation, the I/O is sent asynchronously using UDP. With Uncompressed, 48k/16bit encoding, a delay of about 50ms or less can be expected. I/O transmission is almost immediate. In addition to the above delay, of course, network delays need to be accounted for.
For the STL application, RTP is used as the transport. TCP is not really suitable for this application, especially if low latency is required, due to its unpredictable and time-consuming retry handling.
Due to the uncompressed nature of the sampled audio, a constant network load of rouhgly 1.6MBps per stream target will be generated. Beware – this is more than a common “T1” or ADSL link.
Compression u/A-law can be configured in the STL application, however, the end-to-end delay significantly increases (min. 200ms).

If TCP/shoutcast/icecast protocols should be supported, then standard Instreamer and Exstreamer or Streaming Client Firmware must be used.

===Full Duplex Audio Bridge===

For full duplex audio bridging applications, either the STL application or the “Annuncicom full duplex” applications can be used. For broadcast/radio applications, the STL application should be best matching.

NOTE: Full duplex functionality is limited to sample rates up to 24kHz and point-to-pont applications.

=== Shoutcast/Icecast encoder===

If shoutcast/Icecast streaming is required, use the Instreamer firmware

=== Internet Radio Receiver===

For almost all cases, the Streaming Client firmware with its backup capabilities is the best choice.

=== Radio Syndication, Audio and Contact closures===
Currently, Barix customers are using Instreamer 100s and Exstreamer 100s loaded with the Streaming Client firmware to transport syndicated content, however this lacks the transport of contact closure states that could be used, e.g. to transmit commands to play the station identification or insert local content.

Barix is developing an application to address this feature, whilst keeping low bandwidth requirements. If bandwidth is not an issue, the STL application can be used here, provided that the number of destinations is small or Multicast can be used.

=Hardware=

=== Audio Interfaces===

In contrast to the -100 series products, the Exstreamer 1000 features symmetric (“balanced”) audio inputs and outputs as well as an AES/EBU interface (for both input as well as output).
The audio signals, as well as the AES/EBU interface, are provided on ITT Cannon connectors commonly known as DE-9/DB9. These high quality, screw lockable connectors are very commonly used for serial connections, and also in many areas where higher density connections are needed. Broadcasters often are interested in “XLR” connectors. Due to the many functions and interfaces and the decision to pack the Exstreamer 1000 in a ½ size 19'' case, the use of XLR connectors was not possible (space constraints).
Barix offers an interface “cable set” which contains adapter cables between DB9 and XLR connectors. This cable set is available as an option. For “fixed” installations (such as in STL applications), it is recommended that the installer uses DB9 connectors with direct wiring instead of using XLR connectors.

=== A/D converter===
The Exstreamer 1000 contains a high quality A/D converter which ise used with 32kHz and 48kHz sample rate settings. If other sample rates are used, the A/D converter in the DSP is used.

== AES/EBU==

The AES/EBU Interface can be used with 32kHz and 48kHz sample rates and 16bit audio samples. Other sample rates are not supported.

== Case size and mounting options==

The Exstreamer 1000 case is ideally suited for 19'' rack mounting. Due to its dimensions, two devices can be mounted in 1 HU rack space next to each other, using either standard 19'' equipment holders, or – better- using the Barix 19'' rack mounting bezel. Using the Barix bezel, the front plate, together with the bezel, forms a flat, full size surface, so “piles” of devices mount easily. The “-100” series products also can be mounted on the same 19'' bezel, and need 1/4th width, so any combination of -1000 devices (using ½ width) and -100 devices can be mounted. Attention: the devices are screwed onto the rack mount bezel and are not “slide in/out”.

Back to [[Main Page#Products]]

Exstreamer 1000

2010-02-09T10:47:09Z

Brain: contact closures are available since v3.16

The Exstreamer 1000 combines the instream and exstream technologies into a single device. It is a versatile network device suited for a variety of high quality audio applications.
The Exstreamer 1000 can be used as an audio decoder (Exstreamer functionality), or as an audio encoder (Instreamer functionality). Audio can also be transmitted bidirectionally in a full duplex configuration (ABCL application).

[[Image:Exstreamer1000_FrontPlate_Web800.gif|200px|thumb|right]]
[[Image:Exstreamer1000_RearPlate_Web800.gif|200px|thumb|right]]

The Exstreamer 1000 features:

- Balanced I/O (DSUB9 XLR adapter cable available as an option)

- AES/EBU fully digital transmission path

- High quality A/D converter

- Contact closure interfaces (4 inputs, 4 relays)

NOTE: HW features availability is related to the specific Firmware loaded on the device

=Firmware=

The Exstreamer 1000 is a universal hardware platform and can run various Barix application firmwares. All audio application firmwares provided for download on the website support the Exstreamer 1000. Firmare packages and documentation is available free of charge from Barix.
The following standard application firmware from Barix can be used:

===Instreamer Standard FW===

http://www.barix.com/downloads/Instreamer_Family/81/

Turns the Exstreamer 1000 into a high quality audio encoder supporting MP3 compression, shoutcast/icecast source protocol, RTP broadcast/multicast and raw TCP streaming.

Contact closures are supported in the Instreamer firmware in combination with RTP since the version 3.16.

USB flash memory interface is not supported in the Instreamer firmware.

===Exstreamer Standard FW===

http://www.barix.com/downloads/Exstreamer_Family/71/

Turns the Exstreamer 1000 into a high quality audio decoder supporting MP3 compression, uncompressed playback, RTP/raw UDP/TCP stream reception, synchronous audio playback etc. Serial port tunneling for the RS-232 port is supported, and the serial port can also be used as a command interface.

Contact closures are NOT yet supported in the Exstreamer standard firmware.

USB flash memory interface is not supported in the Exstreamer firmware.

===Streaming Client FW===

http://www.barix.com/downloads/Streaming_Client_Firmware/1381/

Turns the Exstreamer 1000 into a high quality stream receiver with MP3 compression and uncompressed audio support. The Streaming Client firmware allows configuration of up to 3 URLs, with auto-fallback in case of link/server failure, use of a USB flash stick for backup audio in case of higher priority stream failures etc. All standard functionality of the Streaming Client firmware is supported.

Contact closures are NOT yet supported in the Streaming Client firmware.

===STL application ABCL FW===

http://www.barix.com/downloads/ABCL_Applications/1911/

This ABCL-based application is intended for unidirectional, high quality, uncompresssed streaming of mono or stereo audio feeds. Contact closures are supported by this application, and sent to the receiver(s) using standard UDP (separate “channel”). The target address for the stream can be a device IP address, Multicast group or the Broadcast address. Up to 4 destinations can be independently configured for the stream.
In case of a point-to-point application, contact closures can also be sent back.

For sample rates up to 24kHz, the STL application firmware also allows full duplex audio transmission (uncompressed).

===Preloaded ABCL kit FW===

http://www.barix.com/downloads/ABCL_Kit_Firmware/21/

By selecting the specific application (drop down menu) the Exstreamer 1000 can be used as Recorder audio in MP3 and store to a USB stick or a server, as a network MP3 audio Player, as an Intercom Client, as an Intercom Master, as a Full Duplex intercom component, or even as a SIP Client for VOIP phones!

=Applications=

Different applications with different characteristics need different Firmware. The following is a list of typical applications and which software is recommended to be used:

=== STL – Studio Transmitter Link===

The Exstreamer 1000 is ideally suited to set up studio transmitter links over IP infrastructure, being it Ehternet, wireless, LAN, optical fibre or WAN connections.
RTP STL application (ABCL firmware) is supporting full-duplex application for uncompressed analog audio and half-duplex MP3 digital audio stereo streaming at up to 48kHz sample rates.
Along with the Audio, I/O (4 contact closures) can be transmitted. In the current implementation, the I/O is sent asynchronously using UDP. With Uncompressed, 48k/16bit encoding, a delay of about 50ms or less can be expected. I/O transmission is almost immediate. In addition to the above delay, of course, network delays need to be accounted for.
For the STL application, RTP is used as the transport. TCP is not really suitable for this application, especially if low latency is required, due to its unpredictable and time-consuming retry handling.
Due to the uncompressed nature of the sampled audio, a constant network load of rouhgly 1.6MBps per stream target will be generated. Beware – this is more than a common “T1” or ADSL link.
Compression u/A-law can be configured in the STL application, however, the end-to-end delay significantly increases (min. 200ms).

If TCP/shoutcast/icecast protocols should be supported, then standard Instreamer and Exstreamer or Streaming Client Firmware must be used.

===Full Duplex Audio Bridge===

For full duplex audio bridging applications, either the STL application or the “Annuncicom full duplex” applications can be used. For broadcast/radio applications, the STL application should be best matching.

NOTE: Full duplex functionality is limited to sample rates up to 24kHz and point-to-pont applications.

=== Shoutcast/Icecast encoder===

If shoutcast/Icecast streaming is required, use the Instreamer firmware

=== Internet Radio Receiver===

For almost all cases, the Streaming Client firmware with its backup capabilities is the best choice.

=== Radio Syndication, Audio and Contact closures===
Currently, Barix customers are using Instreamer 100s and Exstreamer 100s loaded with the Streaming Client firmware to transport syndicated content, however this lacks the transport of contact closure states that could be used, e.g. to transmit commands to play the station identification or insert local content.

Barix is developing an application to address this feature, whilst keeping low bandwidth requirements. If bandwidth is not an issue, the STL application can be used here, provided that the number of destinations is small or Multicast can be used.

=Hardware=

=== Audio Interfaces===

In contrast to the -100 series products, the Exstreamer 1000 features symmetric (“balanced”) audio inputs and outputs as well as an AES/EBU interface (for both input as well as output).
The audio signals, as well as the AES/EBU interface, are provided on ITT Cannon connectors commonly known as DE-9/DB9. These high quality, screw lockable connectors are very commonly used for serial connections, and also in many areas where higher density connections are needed. Broadcasters often are interested in “XLR” connectors. Due to the many functions and interfaces and the decision to pack the Exstreamer 1000 in a ½ size 19'' case, the use of XLR connectors was not possible (space constraints).
Barix offers an interface “cable set” which contains adapter cables between DB9 and XLR connectors. This cable set is available as an option. For “fixed” installations (such as in STL applications), it is recommended that the installer uses DB9 connectors with direct wiring instead of using XLR connectors.

=== A/D converter===
The Exstreamer 1000 contains a high quality A/D converter which ise used with 32kHz and 48kHz sample rate settings. If other sample rates are used, the A/D converter in the DSP is used.

== AES/EBU==

The AES/EBU Interface can be used with 32kHz and 48kHz sample rates and 16bit audio samples. Other sample rates are not supported.

== Case size and mounting options==

The Exstreamer 1000 case is ideally suited for 19'' rack mounting. Due to its dimensions, two devices can be mounted in 1 HU rack space next to each other, using either standard 19'' equipment holders, or – better- using the Barix 19'' rack mounting bezel. Using the Barix bezel, the front plate, together with the bezel, forms a flat, full size surface, so “piles” of devices mount easily. The “-100” series products also can be mounted on the same 19'' bezel, and need 1/4th width, so any combination of -1000 devices (using ½ width) and -100 devices can be mounted. Attention: the devices are screwed onto the rack mount bezel and are not “slide in/out”.

Back to [[Main Page#Products]]

Default Configuration Customization

2009-12-14T16:08:23Z

Brain: /* Standard Firmware Package */

= Default Configuration Customization=

How to customize the default configuration settings of your Barix Audio product.

WARNING: The following tips are intended only for expert users of Barix products as they may cause misconfiguration of the devices.

==Standard Firmware Package==

The configuration information are contained in one file

► '''config.bin''' located in folder "webuidevkit/xxxxapp" where xxxx depends on the SW package.

The same file is copied also in folder "update_rescue".

In order to create a custom version of the Default Configuration you need to do the following:

# change with binary-editor the configuration values in the '''config.bin''' file
# run the web2cob command (batch file available in the package) to generate the file '''xxxxapp.cob'''
# copy the config.bin and the xxxxapp.cob file in the update-rescue folder
# run the load_win command (batch file gen.bat available in the package) to generate the '''compound.bin''' file

NOTE: the configuration parameters mapping can be found in the Technical Documention of the Firmware

==ABCL Firmware/Application Package==

The configuration information are contained in two different files

► '''config.bin''' located in folder "webuidevkit/abclapp" for the common abcl settings

► '''appconfig.bin''' located in folder "bcldevkit" for the application specific settings

These 2 files are merged in a new config.bin file in folder "update_rescue".

In order to create a custom version of the Default Configuration you need to do the following:

# change with binary-editor the configuration values in the '''config.bin''' file (1)
# run the web2cob command (batch file abclapp.bat available in the package) to generate the file '''abclapp.cob'''
# change with binary-editor the configuration values in the '''appconfig.bin''' file (2)
# run the tokenizer and web2cob commands (batch file applctns.bat available in the package) to generate the file '''applications.cob'''
# merge the two configuration files into one (e.g. use "cat" from command-line: cat config.bin appconfig.bin > config.bin)
# copy the config.bin, abclapp.cob and the applications.cob file in the update-rescue folder
# run the load_win command (batch file gen.bat available in the package) to generate the '''compound.bin''' file

NOTE (1): the configuration parameters mapping can be found in the Technical Documention of the Firmware

NOTE (2): the configuration parameters mapping can be found in the EEPROM layout Documention in the same folder

FW Update

2009-08-05T15:33:05Z

Brain: /* Detailed procedure */

=Firmware Update=
There are 3 methods for operating a FW upgrade on a Barix audio devices: WEB update, Serial Rescue, Gold Unit. Each of them is suited for a different situation and purpose.

==WEB update==

The WEB update is done via a standard WEB Browser running on a PC. The device needs to be running on and visible to the IP network.

This method is suited for field upgrade of the FW. It will not change the current configuration settings.

You may need to force the Factory Default (keep reset button pressed 5-10 sec until lights change blinking) if you have major FW differences (implying a different EEPROM layout).

=====Detailed procedure=====
(as per _readme1st.txt file provided in the rescue package)

1. Open a browser and type the announced IP address into the URL field and hit the ENTER key.

2. Click on the UPDATE button to enter the update page.

3. Click on "Please click here to continue" to launch the update process. The device will restart in a special mode called Bootloader showing a number counting down. Upon start up the following screen appears ready for the update process.

4. To upload an update click on "Browse" to locate the file you want to update. Browse to the folder "update_rescue" and choose the file compound.bin.

5. Once selected, click on "Upload". This process can take a few minutes. After a successful upload click on the "update" link and when the Update window reappears click the "Reboot" button or if there is no button, click on Browse and select the file "reboot". The device will reboot with the new firmware.

==Serial Rescue==

The Serial rescue operation is done via a serial cable and requires a command shell opened on a local PC.

This method is suited for Rescue operation as it will also load the Boot-loader and restore the Default Settings.

So if you need to keep the actual configuration settings:

Open a browser and type the announced IP address followed by "/status" into theURL field and hit the ENTER key.

Print this page which contains the current configuration settings of the device in order to reenter them after the update.

=====Detailed procedure=====
(as per _readme1st.txt file provided in the rescue package)

1. Unplug power supply.

2. Connect the supplied serial crossover cable to your PC's serial port and to the devices serial port.

3. Start The following script in the folder "update_rescue" depending on your Barix device model and COM port you are using:

Exstreamer 100/200 Exstreamer Legacy (red box, Digital, Gold)
Instreamer 100 Instreamer Legacy
Annuncicom 100 Annuncicom Legacy
IPAM
-----------------------------------------------------------
COM 1 ipamres1.bat rescue1.bat
COM 2 ipamres2.bat rescue2.bat
COM 3 ipamres3.bat rescue3.bat
COM 4 ipamres4.bat rescue4.bat

4. A message 'Waiting for the device' will be shown on the bottom of the screen.

5. Plug in the power supply now.

6. Wait until a message 'SUCCESSFUL' appears on the second line.

7. Close the rescue program.

8. Unplug power supply.

9. Plug in the power supply.

10. Your device is set to factory defaults and should work now.

11. Reconfigure the Exstreamer to your last configuration.

== Gold Unit==

Barix Gold Unit is a standard Exstreamer 100 device loaded with a special SW.
The Gold Unit has a USB memory stick attached which contains the binary files to be loaded to the other devices.

The update operation is done via an Ethernet cross cable and optionally requires a serial Terminal running on a local PC for monitoring.

This method is suited for programming in production and can be tailored in terms of modules to be loaded.

If customer needs new Default Settings to be loaded, Barix can provide a customized version of the configuration file (config.bin).

=====Detailed procedure=====

''Prepare USB files''

The files on the USB sticks must follow a name convention in order to be loaded automatically i.e. a file on the memory
stick called WEB03 will be loaded into the flash page 3, a file named WEB10 will be loaded into the flash page 10 and so on.
The file FBOOT will replace the bootloader. The name EEPRO is used to write to the configuration memory (i.e. the eeprom).

The files will be available soon in standard rescue kits.

''Update new Units''

For the units to be loaded containing already a firmware the user would need to:

1. attach the unit to be updated to the Gold Unit via Ethernet connection (direct cross cable or isolated switch) with DHCP enabled (no fixed IP allowed).

2. start the unit to be updated in the boot-loader mode (by keeping the reset button pressed during start-up).

3. after a short delay (1-2seconds) the boot-loader comes up and the file transfer will start automatically. The update operation will be completed in few seconds.

Optionally use a serial Terminal on the unit to be updated to verify that the download is started and finished OK.

Streaming Client Server Authentication

2009-05-22T14:00:09Z

Brain: /* Authentication to a Shoutcast/HTTP server */

== Why authentication ==
Sometimes it is useful to authenticate a Streaming Client unit to the streaming server, e.g. for dynamically generated playlists or streams.
This is especially needed in large installations with hundreds or thousands of devices.

There are two main reasons for authentication:
# identification - to identify the end point and deliver the proper content
# security - no one else is allowed to receive the stream

The Streaming Client does not implement high-level security but rather "reasonable precautions to prevent unwanted user to listen to the music".

== Available methods ==

Streaming Client offers several methods of identification/authentication of the device:
* using the unique MAC address
* in some cases a username/password can be used
* using the IP address
* using the configured DHCP name

MAC address, IP address and DHCP name can be included anywhere in any URL using the variables $MAC$, $IP$ and $NAME$ respectively.

Device's MAC address is provided in every outgoing HTTP request header as a special parameter:
''Pragma: MAC=00:08:E1:xx:yy:zz''

== Proxy authentication ==
# Streaming Client can authenticate to the proxy using a username/password pair. Only the HTTP BASIC authentication is supported.
# If supported by the Proxy the special parameter "Pragma: MAC" can be used for unique identification as well.

== Authentication to a Shoutcast/HTTP server ==
# Using a username/password pair in the URL, e.g. ''http://john:MySecretPassword@my.server.com/radio123.m3u''
# By putting the MAC address (IP address or DHCP name) directly to the URL, e.g. ''http://my.server.com/stream.cgi?mac=$MAC$''
# By parsing the special parameter "Pragma: MAC" on the server to uniquely identify the client.

== Authentication to a BRTP server ==
The unit's MAC address is sent in every BRTP request.

== Authentication in RTP ==

As RTP is actively sent by the server there is no method of end-point identification.

Streaming Client Server Authentication

2009-05-22T13:59:53Z

Brain: /* Authentication to a Shoutcast/HTTP server */

== Why authentication ==
Sometimes it is useful to authenticate a Streaming Client unit to the streaming server, e.g. for dynamically generated playlists or streams.
This is especially needed in large installations with hundreds or thousands of devices.

There are two main reasons for authentication:
# identification - to identify the end point and deliver the proper content
# security - no one else is allowed to receive the stream

The Streaming Client does not implement high-level security but rather "reasonable precautions to prevent unwanted user to listen to the music".

== Available methods ==

Streaming Client offers several methods of identification/authentication of the device:
* using the unique MAC address
* in some cases a username/password can be used
* using the IP address
* using the configured DHCP name

MAC address, IP address and DHCP name can be included anywhere in any URL using the variables $MAC$, $IP$ and $NAME$ respectively.

Device's MAC address is provided in every outgoing HTTP request header as a special parameter:
''Pragma: MAC=00:08:E1:xx:yy:zz''

== Proxy authentication ==
# Streaming Client can authenticate to the proxy using a username/password pair. Only the HTTP BASIC authentication is supported.
# If supported by the Proxy the special parameter "Pragma: MAC" can be used for unique identification as well.

== Authentication to a Shoutcast/HTTP server ==
# Using a username/password in the URL, e.g. ''http://john:MySecretPassword@my.server.com/radio123.m3u''
# By putting the MAC address (IP address or DHCP name) directly to the URL, e.g. ''http://my.server.com/stream.cgi?mac=$MAC$''
# By parsing the special parameter "Pragma: MAC" on the server to uniquely identify the client.

== Authentication to a BRTP server ==
The unit's MAC address is sent in every BRTP request.

== Authentication in RTP ==

As RTP is actively sent by the server there is no method of end-point identification.