Broadcast Dialog

• Server
  The server name. Internet name resolution is used to determine from the server name an IP address. It is possible to give in this field directly an IP address.
• Mountpoint
  The server will list each stream under a different internal name, called the mount point.
• Port
  Any internet connection reaches a machine through a port. For different services different ports are used. For example port 80 is typically used by the http protocol, and in the same way, port 8000 and 8001 is typically used by mp3 audio streams.
• Password
  The application that sends data to a server typically needs to authenticate itself. For authentication, a password is used. This password is given here.
• User
  If using the HTTP login, the server will need a user name together with the password.
• Login Type
  To broadcast an mp3 stream to the WWW, m3w will establish a connection to a server. Except if using UDP, the server will conduct a short chat with m3w to exchange certain information, that is given in other fields of this dialog window. To facilitate this conversation, there are four different protocols available: the x-audio login, the http login, the icy login, and the udp mode.With the radio button you select the login style that m3w will use to talk to the server. If you use the icecast 1 server, you should use the x-audio login. The new version of the icecast server, icecast 2, understands the http login. Both servers, as well as the shoutcast server, speak also the icy protocol. Which, however, is somewhat outdated and should be avoided if possible. If you don't know what to use, just try.If you choose UDP, there is no exchange of login information, m3w just starts sending the data. Further, udp is a lossy protocol. There is no check for lost packages. So if your line is busy, packets may get lost. On the other hand, UDP is slightly faster then TCP, since no bandwidth is needed for the TCP handshake.

  Here is a summary:

  Protocol	Icecast 1.x	Icecast 2.x	Shoutcast	Notes
  x-audio	Best	Works	None	Requires Mountpoint, user, and password
  http	None	Best	None	Requires Mountpoint, user, and password
  icy	Works	Works	Best	Only uses password. User and mountpoint are ignored. Also when using Shoutcast, the port must be 1 higher than the server base.
  udp	Last Resort	Last Resort	Last Resort

• Name
  The Name of the Stream. This information is only for the human observer and of no internal use. The server might display this text along with other information about the data stream to help the listener select a ream to listen to.
• Genre
  Describes the Genre, that is the type of sound that this stream contains.
• URL
  This is an URL (a Universe Resource Locator) where the interested Listener can get more Information.
• Description
  A description of the streams content.
• Dumpfile
  A Filename that (may be) used by the server to store all the data of the stream.
• Private
  A Flag indicating that this stream is available to the general Public or is considered private and only available to certain (server configured) users.
• Buffer
  The data that is coming from the encoder or the input file is entered into a buffer. This is necessary if the data can not be send immediately to the internet. As soon as the internet connection is ready to transmit data, the data from the buffer is send to the server. The default buffer setting should be enough to cope with fluctuations in the availability of transmission capacity. If there is not enough bandwidth available in the long run, the buffer will gradually fill. A progress bar in the main window will show this condition. In this case you should reduce the encoding bitrate. If, however, your internet connection is capable to transmit large quantities of data periodically and is slow otherwise, more buffering might help.
• Automatic Reconnect
  This group of settings is concerned with automatically building a new connection to the server in case some problems caused an existing connection to collapse.
  • To enable this feature, check the Enable box.
  • The Number of Retries tells m3w how often it should attempt to establish a new connection until finally giving up.
  • The Initial Delay tells m3w how many seconds to wait after the problem with the connection is detected before making the first attempt to reestablish a new connection.
  • The Delay tells m3w how many seconds to wait, after a retry has failed before attempting an additional retry.

  To understand these parameters more fully some remarks might be helpful:

  First, how do we know what is a try and what is a retry? A retry requires a successful connection to occur first. What is successful? Somewhat arbitrarily m3w decides that after being able to transmit 10000 Byte the connection was successful. The consequence is the following: Imagine that you have started a broadcast and specified 3 Retries. After about an hour (certainly this was a successful connection) your connection fails. m3w waits for the initial delay and then starts a retry (the first), the connection is set up, the login data is send, but the server refuses the connection (may be busy). This is not a successful connection and after waiting a while, as given by the delay, m3w starts an other retry (the second). This time, all goes well and m3w sends data for another 10 minutes before chaos strikes again. Now, was this a successful connection? If yes, m3w has 3 fresh attempts to reestablish the connection, if not, well, then m3w would have only one attempt left before giving up.(By the way, with any reasonable bitrate 10000 Byte is only a matter of seconds, where as the login data is only some hundred bytes.)

  Last not least, why a separate initial delay? If the connection breaks, your server will keep your mountpoint for a certain time. If you reconnect fast enough, you can continue your broadcast. But if you use a dial-up line, chances are that your service provider will assign you a new IP address when you reconnect. Because of the new IP number, the server will think you are someone different and will not give the old mountpoint to you. Your connection attempt will fail. In this case, it is better to wait until the server has released the mountpoint and then acquire it anew.