I'm new with linux and especially with sound system. I've read many articles about this subject but I'm still confused. I know that Alsa provides audio functionality to the rest of the system. This mean that Alsa is lowest "layer" on sound system (after hardware itself). I also know that ALSA by itself can only handle one application at a time. So here are my questions:
1)Is PulseAudio a bridge to provide usage of Alsa for multiple apps?
2)Are Gstreamer, Phonon and Xine same bridge programs as PulseAudio?
3)Is Alsa converting analog signal into digital signal?
My questions may seem stupid. Thank you.
The OSI model isn't really a good fit to ALSA, as it really only provides layer 1.
PulseAudio is an audio server and is the single client of a ALSA device interface. It provides something analogous to Layer 7 of the OSI model to applications. It mixes the audio output streams from each client application connection down to a single stream for output. It provides an alsa-compatible interface to audio client software (e.g. GStreamer and Xine) which acts as a proxy and connects to the audio server.
Analogue to digital (and digital to analogue) conversion takes place in hardware in what is referred to, rather confusingly, as a CoDec.
Related
Can anyone please elaborate following questions?
How bluetooth stack handles audio data?
How audio commands are processed?
Did we need any service to process audio data?
Thanks in advance.
Basically, voice commands over BLE require:
some audio codec for reducing required bandwidth (ADPCM and SBC are common, OPUS is emerging),
some audio streaming method through BLE,
decoding and getting the audio stream from BLE daemon to a command processing framework.
In the android world, command processing framework is google sauce (closed) that most easily gets its audio from an ALSA device. What is left to be done is getting audio from the remote to an ALSA device.
So for audio streaming, either you:
use a custom L2CAP channel or a custom GATT service, this requires a custom android service app and/or modifications to Bluedroid to handle those, it will need a way to inject audio stream as ALSA, most probably with a "loop" audio device driver,
declare audio as custom HID reports, this way, Bluedroid injects them back to the kernel, then add a custom HID driver that processes these reports and exposes an audio device.
Audio over BLE is not standard, so all implementations do not do the actual same thing. In Nexus Player case, implementation uses HID: It streams an ADPCM audio stream, chunked in HID reports. There is a special HID driver "hid-atv-remote.c" in Android linux kernel that exposes an ALSA device in addition to input device. Bluedroid has no information about audio, all it does is forwarding HID reports from BLE to UHID.
I am new to PulseAudio and ALSA, so please go easy on me. This might seem like a dumb question, but it is quite important to have it answered.
I am developing application on ARM imx6 board (lets call it BOARD1), with built-in sound card support. With ALSA, I am able to play audio throgh Headset_OUT. But now, we want to move to a new board (lets call it BOARD2), which does not have built in soundcard. But the idea is to connect a bluetooth module to the BOARD2 and have the audio streamed to the bluetooth speaker.
My question is, is it possible to use PULSEAUDIO to send/receive audio to external (bluetooth) audio device without local embedded soundcard (i.e. is it possible to do audio encoding/decoding in just software with pulseaudio and gstreamer combination) ?
Regards
I have a project that I am working on, for the purposes of this question, lets say they are wireless speakers.
We are using the raspberry pi for development right now but we plan to move to our own embedded solution. The codec we've chosen fits our needs best, although it isn't an "ALSA supported" codec. As in the ALSA webpage doesn't have info on it.
Much of the PCM code I've found to develop this on the raspberry pi use ALSA streams. Is it a standard to use an ALSA codec for these types of projects?
I haven't worked much with embedded linux or RTOS. I work with bare-metal systems quite frequently though which explains my confusion on what ALSA exactly is. It seems like some odd middleware or something.
ALSA is
the API that application that want to use sound use; and
the library that implements this API; and
the interface between this library and the kernel; and
the kernel implementation of this interface; and
the framework to be used by sound drivers.
To have your codec supported in Linux, you must write an ALSA driver.
Suppose that I want to code an audio filter in C++ that is applied on every audio or to a specific microphone/source, where should I start with this on ubuntu ?
edit, to be clear I don't get how to do this and what is the role of Pulseaudio, ALSA and Gstreamer.
Alsa provides an API for accessing and controlling audio and MIDI hardware. One portion of ALSA is a series of kernel-mode device drivers, whilst the other is a user-space library that applications link against. Alsa is single-client.
PulseAudio is framework that facilitates multiple client applications accessing a single audio interface (alsa is single-client). It provides a daemon process which 'owns' the audio interface and provides a IPC transport for audio between the daemon and applications using it. This is used heavily in open source desktop environments. Use of Pulse is largely transparent to applications - they continue to access the audio input and output using the alsa API with audio transport and mixing. There is also Jack which is targeted more towards 'professional' audio applications - perhaps a bit of a misnomer, although what is meant here is low latency music production tools.
gStreamer is a general purpose multi-media framework based on the signal-graph pattern, in which components have a number of inputs and output pins and provide a transformation function. A Graph of these components is build to implement operations such as media decoding, with special nodes for audio and video input or output. It is similar in concept to CoreAudio and DirectShow. VLC and libAV are both open source alternatives that operate along similar lines. Your choice between these is a matter of API style, and implementation language. gStreamer, in particular, is an OO API implemented in C. VLC is C++.
The obvious way of implementing the problem you describe is to implement a gStreamer/libAV/VLC component. If you want to process the audio and then route it to another application, this can be achieved by looping it back through Pulse or Jack.
Alsa provides a plug-in mechanism, but I suspect that implementing this from the ALSA documentation will be tough going.
The de-facto architecture for building effects plug-ins of the type you describe is Steinberg's VST. There are plenty of open source hosts and examples of plug-ins that can be used on Linux, and crucially, there is decent documentation. As with a gStreamer/libAV/VLC, you be able to route audio in an out of this.
Out of these, VST is probably the easiest to pick up.
Is there a way to stream all audio from a laptop (which has low quality speakers) to a desktop with much better speakers in linux (on both computers)? I think that this would have to be a kernel driver, since it would have to fit under the alsa system to make it application transparent.
Thanks,
Andrew
Pulseaudio has network support, and it is the only way I know of to do low-level sound device streaming.