I want to be able to process audio output of applications (VLC, Rhythmbox, ...) within my own one. Moreover, one should be able to select my application as the sink for the sound (e.g., in VLC or pavucontrol my application should appear as an output device).
How is this possible? Can it be done with ALSA, Pulseaudio, ...? Currently I am seeking for the easiest solution while later performant ones may become preferable. It would be great if most of the configuration could be done via API calls.
Thank you for your support!
I ended up writing a PulseAudio module. There one can create own sinks and directly get access to the audio stream. Have a look at my implementation here.
Related
i want to run 2 different BackgroundTasks - one for the communication with my arduino - and one for the communication with other devices by using a webservice. These tasks should be able to write and read from ONE database. But my problem is, that the Windows.Storage.ApplicationData does not provide the SharedLocalFolder. It is null, if I want to use it. Is there any other way where i can store my database that both BackgroundTask can connect to it?
Additionally I found now this path:(Windows.Storage.ApplicationData.Current.GetPublisherCacheFolder(...)). This look very interesting, but if i want to use it I cant write there. I think, because the resolved file path does not exist..
Any other ideas?
Sincerely,
App2App Communication via WebServer (Blinky WebServer):
You can refer Microsoft's IoT sample provided for Blinky Webserver which also depicts the concept of App2App Communication. But you need to read it thoroughly to modify and reuse it up-to your expectation.
Right now I have no experience about Windows IoT and database. Once I got my hands on it, I'll update.
I would like to use C in order to get the last time the soundboard was playing a file. Is there a way I could do that?
None of the components you are using (tools, libraries, sound servers, drivers, kernel) logs the time when a sound is played.
If you are using one specific tool to play sounds, you could modify it to log the time.
Otherwise, you have to actively monitor the current status of the sound device.
(With ALSA, you could poll /proc/asound/card*/pcm*/sub*/status.)
I think it's not possible because of ALSA(Advanced Linux Sound Architecture) is just kernel component that provide device drivers for sound card.But i don't know if some user-space API's and library's like (alsa-ustils) can do that!,I advice may is better to check Sound-Player applications(VLC etc..) log ?!
I'm working on a streaming audio player for Linux/OS X with a bizarre use case that has convinced me nothing that already exists will work. For the first portion, I just want to receive MP3 data and play it. I'm currently using libmad for decoding and libao for playback. My problem is with libao, and I'm not convinced it's my best option.
In particular, the ao_play function is blocking. It doesn't return until the entire buffer passed to it has been played. This doesn't give enough time to decode blocks between calls to ao_play, so the decoding has to be done either entirely ahead of time, or concurrently. Since this is intended to be streaming, I'm rejecting ahead-of-time decoding offhand. (It's conceivable I could send more than an hour's worth of audio data - I don't want to use that much memory.) This leaves concurrency. But while pthreads is standard across Linux and OS X, many of the surrounding libraries are not. I'm not really convinced I want to go to concurrency - so I'm reconsidering my choice of libao.
For my application, the best model I can think of for audio playback would be getting a file descriptor I could select on to get notified when it's ready for writes, then issue non-blocking writes to. (This is due to the rest of the details of the use case, which imply I really want a select loop anyway.)
Is there a library that works on both Linux and OS X that works this way?
Although it's much hated, PulseAudio basically works exactly like you describe (using the Asynchronous API, not the simple one).
Unless what you want to do involves low-latencies or advanced sound work, in which case you might want to look at the JACK Audio Connection Kit.
PortAudio is your one. It has a simple callback driven API. It is cross-platform and low-latency. It is the best solution if you don't need any fancy features (3D, audio-graphs,...).
I've been assigned to upgrade an embedded application written in C. The application is configured via a web interface.
When the user modifies the web application a file is written to /var/www/settings.json and the file /var/www/UPDATE_SETTINGS is touched.
In the main application loop it checks to see if UPDATE_SETTINGS exists. If it does it parses the settings.json with json-c and then deletes UPDATE_SETTINGS.
This works well enough, however, we would prefer to move to an event-driven architecture (perhaps libev) in which settings.json is fed directly into the program by the webapp script to a plain-old UDP port and then issue a callback to perform the update.
What are some other elegant ways to solve this problem? Should we just stick with the current approach?
Just use inotify. It was created for cases like yours.
I am making some assumptions here.
1) you are connected to the internet all the time with you embedded device.
2) your device can set up interrupts on things like "USART RX buffer not empty"
note: depending on what kind of hardware you are using you could set up interrupts on things like pings and other stuff this could be another way of interrupting the embedded device.
if those two assumptions are correct you could do this, have another "script" on a server or computer somewhere that watches the /var/www/settings.json for changes you could use something like rsync to watch for changes. this "script" when it notices that the json file changes will communicate to the embedded device using tcp/ip you can either ping the device or just send the file over. If you can set an USART interrupt on the embedded device then the device will be able to detect the data coming in and therefore respond by either reading the data you are sending or going to the website to download the json file to be parsed.
this way you will have an event drive embedded device and it will not waste time checking to see if this json file has changed.
I hope this helps
The user, administrators and support staff need detailed runtime and monitoring information from a daemon developed in C.
In my case these information are e.g.
the current system health, like throughput (MB/s), already written data, ...
the current configuration
I would use JMX in the Java world and the procfs (or sysfs) interface for a kernel module. A log file doesn't seem to be the best way.
What is the best way for such a information interface for a C daemon?
I thought about opening a socket and implementing a bare-metal http or xmlrpc server, but that seems to be overkill. What are alternatives?
You can use a signal handler in your daemon that reacts to, say USR1, and dumps information to the screen/log/net. This way, you can just send the process a USR1 signal whenever you need the info.
You could listen on a UNIX-domain socket, and write regularly write the current status (say once a second) to anyone who connects to it. You don't need to implement a protocol like HTTP or XMLRPC - since the communication will be one-way just regularly write a single line of plain text containing the state.
If you are using a relational database anyway, create another table and fill it with the current status as frequent as necessary. If you don't have a relational database, write the status in a file, and implement some rotation scheme to avoid overwriting a file that somebody reads at that very moment.
Write to a file. Use a file locking protocol to force atomic reads and writes. Anything you agree on will work. There's probably a UUCP locking library floating around that you can use. In a previous life I found one for Linux. I've also implemented it from scratch. It's fairly trivial to do that too.
Check out the lockdev(3) library on Linux. It's for devices, but it may work for plain files too.
I like the socket idea best. There's no need to support HTTP or any RPC protocol. You can create a simple application specific protocol that returns requested information. If the server always returns the same info, then handling incoming requests is trivial, though the trivial approach may cause problems down the line if you ever want to expand on the possible queries. The main reason to use a pre-existing protocol is to leverage existing libraries and tools.
Speaking of leveraging, another option is to use SNMP and access the daemon as a managed component. If you need to query/manage the daemon remotely, this option has its advantages, but otherwise can turn out to be greater overkill than an HTTP server.