Main Page | Modules | Data Structures | File List | Data Fields | Globals | Related Pages

Alsad Overview

Abstract

This paper describes my implementation of alsa_client and alsad, client and server applications written for the GNU/Linux operating system, which give users the ability to create audio streams with user-defined sources and sinks. The current implementation allows the user to create sources and sinks that are sound-card hardware interfaces or clients running alsad's custom network protocol. Alsad transfers sound data from a source to all of the existing sinks. Alsa_client and alsad transfer uncompressed audio data over the network. As a result, these applications are most suited for use on local area networks.

Users of alsad and alsa_client can create an audio stream where the source is a file or a sound-card hardware interface, optionally stream the sound data to multiple alsads with additional sinks, and ultimately write the streamed audio data to a sound-card hardware interface or a file.

Overview

Alsad allows connecting clients to add and delete streams, sources, and sinks. An alsad stream, known hereafter as a stream, is a chronologically ordered flow of sound data with a unique identifier, text description, and properties that define the type of sound data that flows through the stream. A stream may have a source and must have one or more sinks. Alsad places data received from a stream's source into a shared buffer for sinks to consume. As a result, all sinks consume the same data, but may be reading from different parts of the shared buffer. A sink's position in the buffer depends upon the rate at which its destination asks for data.

When a user first adds a stream, it has no source and a sink that alsad automatically creates to discard the stream's data. Once a user creates a stream, he/she can then request that alsad add a source or additional sinks to this stream. If the user chooses to add a source first, the automatically generated sink removes the sources data as soon as it arrives. This action continues until the user adds a sink. If the user adds a sink to a stream before they add a source, the sink waits until the stream contains data to read. Once data is available, the sink reads from the buffer and sends the data to its defined destination. If a user requests that alsad remove a source, any data received by alsad is left for connected sinks to consume.

Sources and sinks for a stream can be sound-card hardware interfaces or clients running alsad's custom network protocol. Sound-card hardware interfaces are the hardware input and output devices located on the sound card. They connect the sound card with external components that attach to the card. Microphones, headphones and low-level input and output devices (both in digital and analog format) use sound-card hardware interfaces to connect with the sound card. Alsad uses the Advanced Linux Sound Architecture (ALSA) libraries to configure and interact with the sound card when a stream has a source or a sink that is a sound-card hardware interface.

A user has three options when determining the rate sound data should flow though a stream. In the first option, alsad calculates the rate of flow based on user-defined stream properties that describe the real-time rate of the stream data. Alsad only allows sources to send data at this rate. All sinks are in turn forced to read at this rate or receive an underrun. With the second option, alsad allows a source to send data as fast as the slowest sink can consume it (if there are no sinks the source is allowed unlimited write permission). This strategy prevents any sinks from receiving an underrun. In the final option, alsad combines the last two strategies by choosing the fastest of: the real-time rate of option one and the slowest-sink rate of option two. This strategy gives a underrun to clients reading slower than the real-time rate and allows sinks to consume faster than real time if there are no real-time sinks.

Clients connected to alsad can also request stored information about existing streams, sources, and sinks. The client can obtain this information by making two different requests. The first request provides clients with a list of general information about defined streams on alsad. This information includes the stream's unique identifier, the textual description of the stream, and properties that define the sound data that passes through the stream. The second request allows clients that specify an existing stream to receive all relevant source and sink information. Alsad sends the unique identifier of the sources and sinks for the requested stream. If the source or sink is a sound-card hardware interface, alsad also includes settings to configure the hardware. In addition to this information, alsad also sends address information for every connected client.

When a client adds a source or a sink that is not a sound-card hardware interface, it must also send a message containing the hostname of the machine on which it is executing. If the connecting client is an alsad, it sends the TCP port on which it accepts connections. Otherwise, the client sends 0 as the TCP port. Storing this information allows intelligent clients to query alsads, using the queries described in the last paragraph, to find alternative locations for a desired stream. Finding an alternative location might be important in situations where clients are consuming a large percentage of an alsad's network bandwidth. This lack of bandwidth may prevent clients from creating a sustainable sink on an alsad. If the desired stream has an existing sink that is an alsad, an intelligent client could try to connect with this alternative. If the alternative alsad is on a network segment with enough bandwidth to handle transporting the desired stream, the client can create a sink for this stream.


Generated on Thu Dec 16 23:07:30 2004 for alsad by doxygen 1.3.6