In computing, the Enlightened Sound Daemon was the sound server for Enlightenment and GNOME. Esound is a small sound daemon for both Linux and UNIX. ESD was created to provide a consistent and simple interface to the audio device, so applications do not need to have different driver support written per architecture. It was also designed to enhance capabilities of audio devices such as allowing more than one application to share an open device. ESD accomplishes these things while remaining transparent to the application, meaning that the application developer can simply provide ESD support and let it do the rest. On top of this, the API is designed to be very similar to the current audio device API, making it easy to port to ESD. ESD will mix the simultaneous audio output of multiple running programs, and output the resulting stream to the sound card. ESD can also manage network-transparent audio. As such, an application that supports ESD can output audio over the network, to any connected computer that is running an ESD server. ESD support must be specifically written and added into applications, as ESD does not emulate normal audio hardware APIs. Since ESD has been around for over a decade, earlier than almost any other sound server, a very large number of Unix applications have support for ESD output built-in, or available as add-ons. ESD was maintained as part of the GNOME project, but as of April 2009, all ESD modules in GNOME have been ported to libcanberra for event sounds or GStreamer/PulseAudio for everything else. PulseAudio 2.0 completely drops ESounD support.
Esound is a stand-alone sound daemon that abstractsthe system sound device to multiple clients. Under Linux using the Open Sound System, as well as other UNIX systems, typically only one process may open the sound device. This is not acceptable in a desktop environment like GNOME, as it is expected that many applications will be making sounds. The ESD daemon connects to the sound device and accepts connections from multiple clients, mixing the incoming audio streams and sending the result to the sound device. Connections are only allowed to clients that can authenticate successfully, alleviating the concern that unauthorized users can eavesdrop via the sound device. In addition to accepting client connections from the local machine, ESD can be configured to accept client connections from remote hosts that authenticate successfully. Applications wanting to contact the ESD daemon do so using the libesd library. Much like with file i/o, an ESD connection is first opened. The ESD daemon will be spawned automatically by libesd if a daemon is not already present. Data is then either read or written to the ESD daemon. For an ESD client local to the machine that the ESD daemon is running on, the data is transferred through a local socket, then written to the sound device by the ESD daemon. For a client on a remote machine, the data is sent by libesd on the remote machine over the network to the ESD daemon. The process is completely transparent to the application using ESD.
