I need some pointers where to start with the following:
From any application that plays audio using ALSA to the connected speaker I'd like to grab the samples and do some audio processing.
I am not in control of the player and I'd like to be able to process the audio from any source. Basically it will be an UV-meter, perhaps later with FFT (all just on the command line). Additionally I'd like my app to be self-contained.
In my research I've found:
There is a loopback kernel module.
You can do fancy stuff with the configuration file.
There is the ability to create plugins.
Using the kernel module and altering the configuration file introduces some dependencies of my application to the configuration of the system.
And creating a plugin I give up control over the app and cannot start/terminate it whenever I want.
This is not satisfactory to me so I'd like to know if there is a way to either:
create a loopback device programmatically
or is there any other way to read from the pcm playback device other applications are writing to.
You can use the pulseaudio for linux where you can very easily create a loopback device .There ia a pactl command -it will help you create a null sink and you can loopback from it .
something like this
//this would create a null sink with specified channel conf
pactl load-module module-null-sink sink_name=sink6ch format=s16le rate=48000 channels=6 channel_map=front-left,front-right,front-center,lfe,rear-left,rear-right
//make it default
pactl set-default-sink sink6ch
you can use its monitor device to read about the monitor devices of pulse audio
Related
I'm using a LPC178 development board and I want to read a file present on a Windows PC. My dev board only has a RS2323 interface to communicate with.
How can I go about transferring the file from my PC to my MCU using a RS232 (serial) link? I found a reference which explains how to transfer data between a MCU and PC but it isn't about file transfers.
Afaik there is no easy solution for this like calling something like "copy" or "fopen" over RS232. I would be happy to be proven wrong here.
The fastest solution might be to write a little programm running on your Windows Host, which listens to your RS232 communication and pipes your communication into/out of the file based on your communication protocol. This can be done with standard file operations in the language of your choice, for example C, C++ or Python.
Your problem is one of the oldest in the book. How do you transfer files without fancy operating system abstractions. For RS232 (or any other serial method) there exists many file transfer protocols.
One of them is kermit. This is a protocol from 1981 and can transfer binary and text files. It is able to be embedded in a micrcontroller and there exists programs to transfer/receive using kermit.
alternative old site for reference
In the simplest case you would use a file transfer protocol such as XMODEM, YMODEM, ZMODEM or Kermit - these protocols were designed in the days before networking and the Internet were ubiquitous and deal with simple point-to-point transfers between two computers. They are supported bu most terminal emulator tools such as TeraTerm Pro or PuTTY so no specific PC software need be written, just the microcontroller end.
A more complex but flexible solution is to implement a TCP/IP stack and a PPP driver, and an FTP application layer - probabaly only practical if using a third-party TCP/IP stack and application layer. You can then use any FTP client for the PC end, so again no PC software required. While this may be overkill if all you need to do is transfer files, it has the advantage of allowing you to use the the single serial port concurrently for other data streams and application protocols such as Telnet. The disadvantage perhaps is that while Windows does support PPP it is buried within the dial-up networking and to be frank a pain to get working.
Very first step you have to do is ensure serial communication is working fine.
Send a byte continuously from mcu to PC and display it on some io console (for example: HyperTerminal, Dock light )
Receive a byte to mcu from PC and echo it back to PC.
Once you are sure that serial communication is working fine then select some file transfer protocol and implement it.
While you can select any of the available protocols or write your own protocol and implement it.
For purpose of discussion i select Xmodem protocol.
If you consider some other protocol you may stop reading answer here.
XMODEM is a simple file transfer protocol.
Refer http://web.mit.edu/6.115/www/amulet/xmodem.htm for detailed information.
You may implement Xmodem mcu side by reading protocol. Or may consider using open source also ( if available )
PC side i prefer to use HyperTerminal io console as it is compatible with Xmodem.
In HyperTerminal all that i have to do is configure settings and select file for transfer to mcu.
Now transfer any file to mcu using Xmodem protocol from PC.
What you do with received file in mcu is up to you : )
I hope to know how to capture audio by using dummy sound card driver.
I'm thinking how to implement the steps below.
we play audio in ubuntu, however the audio is just played through dummy sound card driver, to capture audio stream.
captured audio is sent to windows through network.
audio is actually played in windows.
What you need is to activate ALSA snd-aloop module, that provides a full-duplex virtual loopback soundcard. Please have a look to the following links for instructions about activation and example usage:
https://github.com/TheSalarKhan/Linux-Audio-Loopback-Device
https://sysplay.in/blog/linux/2019/06/playing-with-alsa-loopback-devices/
A couple of important points to consider:
The subdevices are linked in pairs; whatever you play on hw:n,0,m goes out on hw:n,1,m (see the example in the 1st link)
The first application opening one of the subdevices will force the second application to use the same set of parameters: sample rate, format, number of channels. For example, suppose the recording application opens a capture stream on hw:2,1,0 with stereo/44100/S16_LE format; the playback application on hw:2,1,0 will be forced to use a the same stereo/44100/S16_LE format
Hope this helps
Development platform: TI davinci processor with Linux OS
I am developing C program which receives user command over serial port and does the corresponding task. Basic task is to start and stop the video recording. And for retrieving the video to host pc from the embedded device, usb interface is used.
The partition used for storing the video file is loaded as USB gadget mass storage device using following kernel module for the user to save the video on host pc.
modprobe g_file_storage file=/root/usbstorage
But i want to load(or some otherway) this kernel module from the c function whenever user send a command to connect the embedded device to host. And disconnect whenever disconnect command is received.
As of now I'm able to load this module only from the shell.
Could any suggest any possible way of doing this from within the c-program.
I would like to use an arduino with a bluetooth module to modify the volume and skip songs on my phone.
All the information I found was about how to code an application that would communicate with a device via bluetooth, which isn't what I am looking for. I want to know what protocol I should follow to connect to an android device via bluetooth like a car radio would do.
My goal is to be able to use my device as a remote to control the built-in music application.
I think you are looking for the AVRCP protocol. Please send more info about your hardware so I can digg a better answer (if you need more, anyways...).
I am trying to communicate between two XBee S2 modules both in API mode using the XCTU tool.
One device as router and another device as coordinator. I got successful communication of two XBee modules in AT mode and either of them as API or AT mode. But when I configure both of them in API mode they are not communicating.
How do you know they're not communicating? How are you forming your API frames to send into the device?
In API mode, the XBee module requires a checksummed series of bytes in a specific format to send data to another device. During your tests between the module in AT mode and the one in API mode, you were probably able to see a received frame on the API module when typing data into X-CTU on the AT module.
What language are you going to write your program in? I would recommend using a code library to manage encoding and decoding the API frames.
Digi has a webpage listing XBee host libraries in various languages.
After giving a lot of try i found two tricks in configuring X Bee modules
If your X Bee module is not getting read, just write with the suitable firmware
choosing manually
If it is not responding to read or even write also, connect reset pin to
ground using single wire for few second.