MPD simply runs in the background playing music from its playlist. Since Volumio and RuneAudio are using MPD, It is a good idea to select MPD and figure out how it works. This may not be an issue as modern applications do not have a need to use the older OSS v3 interface. Output using a wrapper API which outputs using any of the above 3 methodsĪ further simplification is to restrict the use of ALSA through the ALSA API (a more modern API) and avoid using the OSS v3 API (Legacy API).Output using OSS version 3 API directly to ALSA’s Kernel API.Output using ALSA API to sound mixer, which outputs to ALSA’s Kernel API (when sound mixing is enabled).Output using ALSA API directly to ALSA’s Kernel API (when sound mixing is disabled).And indeed it can be bypassed:Ī sound developer who wishes to output sound in their application can take any of the following routes with ALSA: The key message here is that ALSA looks like a “simple” interface between an audio application and the hardware and that there is a Mixer (Sound Mixing) outside the Kernel that CAN can potentially be bypassed.
A graphical description of ALSA is as follows: This site also has a good overview of the different sound subsystems in Linux. (At least PulseAudio and Jack are are installed when installing MPD) In our case, restricting to ALSA looks like a good option since it is already included in the Debian BBB release. In our quest for bit-perfect audio, A reasonable approach to simplify the audio path is by minimizing the number of components through which the audio stream can possibly travel.Ī practical way to do this is to direct the application to use a single audio subsystem. Audio applications such as MPD can use either ALSA, PureAudio or OSS in order to appeal to a wider audience and provide compatibility to new, old and in-between versions and flavors of Linux. An application can use Alsa, routed through Jack and back to Alsa or it can use PulseAudio to OSS or Alsa all the way. Here is a very simplified and high diagram describing the different audio subsystems and their relationship :Īnd application can literally take any route through the different components in order to arrive at the hardware.
An application can use anyone of these subsystems and in fact they do in order to provide wide appeal and compatibility. To and audio application, Linux audio provides several audio subsystems through which audio can be channeled: ALSA, PulseAudio, Jackd, OSS and others. It enters your Linux box at one point and leaves at another. This is a failure because there’s nothing intrinsically more complicated about audio than any other technology. This soon becomes evident if you sit down with a piece of paper and try to draw the relationships between the technologies involved with taking audio from a music file to your speakers: the diagram soon turns into a plate of knotted spaghetti. There’s a problem with the state of Linux audio, and it’s not that it doesn’t always work.
Here is a depiction of Linux audio (circa 2008) : It is almost ironic that the quest for a “perfect audio appliance” which led us to the “simpler”, low power (the BBB consumes less than 5W) and light-weight world of embedded Linux, has also led us to the incredibly complex world of Linux audio.īecause of its long evolution, long list of requirements from both sound professionals and consumers, and open development environment, many audio subsystems have flourished, each having their own set of unique features, duplicating features from each other, providing interfaces to as many applications (even legacy applications) as possible and attempting to interfaces to each other.
0 kommentar(er)
