I have an USB modem which exports a PCM interface, fed to an I2C audio codec.
The codec is supported as a SoC ALSA codec, and I'm developing a driver to manage the sound levels through ALSA mixers.
I think I have two options:
either create a dummy SoC sound card with the codec as an aux (snd_soc_aux_dev) device. The codec's configuration is fixed in the init() function and ALSA is not managing the PCM interface, just the levels. This way I'm not using all the functions already implemented in the codec's driver to set clocks, rates, formats.
or create a modem sound card which exports a DAI with the correct rate and format parameters. This way I can use the codec driver's implementation of all the functions.
Which place should I put this kind of driver? As an extension to the USB driver, or as a SoC one?
Related
How to write a PCM codec device driver with long/short frame sync(Not I2S) in Raspberry Pi?
I know how to write an Alsa sound architecture device driver with I2S(write a platform device driver and codec driver) but I suppose raspberry only supports I2S in default.
Finally, I found the answer! PCM has several modes for clocks! I2S is one of the others are DSP Mode A and B, left and right justified and raspbian support all of them.
For the use, another PCM mode is:
1- Codec driver supports it!
2- In the snd_soc_dai_link platform driver, choose them.
More information: I2S DSP modes ,Alsa Device Drivers,DAI hardware audio formats.
I have one query regarding ALSA codec registration. I need to connect two Audio codecs to two I2S interfaces of Host. Both Audio codecs are connected separately to each I2S interface.
Can someone point to some link or reference implementation for the same?
Thanks
For editing configuration and all , you can refer
https://unix.stackexchange.com/questions/293450/alsa-send-audio-to-two-audio-devices this link. But for that, your I2S driver should support multiple devices.
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.
What is the difference between ALSA and Pulse Audio ?
What is the use of ALSA and Pulse Audio as applied to A2DP streaming when the my device works as a sink device?
Thanks, Yogesh
ALSA is a driver and API to interface directly with the sound device. It allows low-level reading, writing and device control, as well as some MIDI support. Pulse Audio is a sound server which can use ALSA to access the sound card and also provide network audio and more advanced software mixing/scheduling.
I do not know much about Pulse Audio's implementation of A2DP (if any), however this is not something that ALSA is designed to support.
J
Wanted to know what exactly is the difference between routing the A2DP/SCO packets through PCM and HCI.
Do both PCM and HCI use ALSA framework for decoding the packets and then send it to speakers ?
Does PCM require some special hardware and HCI does not ?
A paper, titled "Audio Streaming over Bluetooth" (PDF) from the Ottowa Linux Summit 2008 may shed some more light on this.
In particular (quoting from page 194):
The audio data transferred over the SCO channel can be
provided via the normal Host Controller Interface (HCI)
hardware driver or via a PCM back-channel. In case
of a desktop computer, the HCI will be used. In case
of an embedded device (for example a mobile phone),
the SCO channel will be directly connected via a PCM
interface to the main audio codec.
A2DP uses ACL packets, voice calls (handsfree) uses SCO packets over the air.
HCI can transport both ACL and SCO, this is the case fx. when a BT dongle is plug'ed into a PC through USB. BT chips often have PCM interface to which SCO data can be routed but usually its not accessible unless you can access the PINs of the chip. The PCM interface can be connected to an analouge input/output.