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,...).
Related
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.
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 ?!
Wacom's drivers have always been atrociously bad, so I'm currently working on a hack.
The main problem I'm having is with calibration on a tablet PC. And before you say anything: no, just no. I've tried literally dozens of drivers, and of the few that work, none allows calibration of Wintab input. You can calibrate MS Ink, but that does nothing for apps like Photoshop that don't support the Ink API.
Having researched the issue a bit, the way I plan to hack it is by writing a wrapper for wintab32.dll which adjusts data packets as they're sent to applications, enabling calibration and perhaps tweaks to pressure sensitivity and whatever else I feel Wacom should have supported all along.
The calibration function is trivial, as is wrapping wintab32.dll and getting at the data that needs calibrating. As far as I can tell there are about half a dozen functions that request packet data, and I've inserted code in each of them to modify said data.
It works, too, at least if I test it on some wintab sample projects.
Photoshop is different, though. I can confirm that it loads the wrapped DLL, opens a wintab context and uses the API to request packet data, which is then modified en route. But then Photoshop ignores the modifications and somehow gets at the original, uncalibrated data and uses that. I can find nothing in the Wintab documentation to suggest how this is even possible.
I'm pretty stumped. Any thoughts?
Could it be that Photoshop only requests packets from Wintab in order to clear the packet queue, and then does something else to actually read the state of the stylus? And if so, what could that be? Some secret, obscure way of polling the data using WTInfo? A hook into the data stream between Wintab and the underlying driver/serial port?
I'm not very sure, but maybe the input from Ink API is also being written on the canvas. I mean, you are writing using two inputs now, which is WinTab and Ink. Got it?
If only you could ignore the Ink input, then that will show the right result.
P/S: This is only a hunch.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How to get PCM data from microphone in C++ (os Windows)?
How can i capture sound from the microphone, and hear it in another computer live?
Thanks.
The simplist way is to use the waveIn functions provided by the Win32 API.
You can read Recording and Playing Sound with the Waveform Audio Interface for an overview, or just dive into the API documentation.
To record, you can use the waveIn functions in win32API.
BUT before you send it, remember that the data got in the byte-buffer through waveIn function is PCM format, and it will easily clog your NETWORK. You must first compress the PCM data into aLaw or uLaw format before tunneling it through WinSOCK Apis. Otherwise, it will surely NOT be a "live" feed, also taking up a lot of bandwidth.
Another easy solution for audio i/o is portaudio. Aside from being portable, it's very easy to use.
To get audio data over the network, as another answer pointed out, you should be aware that your data is huge. However, a good place to start is to try sending raw data. Once you can do that, then you can worry about compressing it -- you need to solve a complex problem one step at a time. Eventually, you'll probably want to use UDP for the raw audio packets.
A good library for sending audio, video, chat and other data is google's libjingle which implements the google talk protocol. It has solved many of the issues with UDP vs TCP, firewalls etc. You may find it a bit hard to work with anyway as it's a lot of code and you'll need to work with XMPP which you may not be familiar with. Also, it's C++, not C. It also requires some server mediation, although you can use google's servers. If that doesn't work for you you can do something home grown but you may find you need to do a fair bit of work to get it all right.
I am sure there are some libraries to help you. Try googling for things like "internet telephony library c" and "voip c library" (even though this is not, in the strictest sense, voip)
I am a beginning C programmer (though not a beginning programmer) looking to dive into a project to teach myself C. My project is music-based, and because of this I am curious whether there are any 'best practices' per-se, when it comes to timing functions.
Just to clarify, my project is pretty much an attempt to build some barebones music notation/composition software (remember, emphasis on barebones). I was originally thinking about using OSX as my platform, but I want to do it in C, not Obj-C (though I know it would probably be easier...CoreAudio looked like a pretty powerful tool for this kind of stuff). So even though I don't have to build OSX apps in Obj-C, I will probably end up building this on a linux system (probably debian...).
Thanks everyone, for your great answers.
There are two accurate methods for timing functions:
Single process execution.
Timer event handler / callback
Single Process Execution
Most modern computers execute more than one program simultaneously. Actually, they execute pieces of many programs, swapping them out based on priorities and other metrics to look like more than one program is executing at the same time. This overhead effects timing in programs. Either the program gets delayed in reading the time or the OS gets delayed in setting its own time variables.
The solution in this case is to eliminate as many tasks from running. The ideal environment is for best accuracy is to have your program as the sole program running. Some OSes provide API for superuser applications to block all other programs or kill them.
Timer event handling / callback
Since the OS can't be trusted to execute your program with high precision, most OS's will provide Timer APIs. Many of these APIs include the ability to call one of your functions when the timer expires. This is known as a callback function. Other OS's may send a message or generate an event when the timer expires. These fall under the class of timer handlers. The callback process has less overhead than the handlers and thus is more accurate.
Music Hardware
Although you may have your program send music to the speakers, many computers now have separate processors that play music. This frees up the main processor and provides more continuous notes, rather than sounds separated by silent gaps due to platform overhead of your program send the next sounds to the speaker.
A quality music processor has at least these to functions:
Start Playing
End Music Notification
Start Playing
This is the function where you tell the music processor where your data is and the size of the data. The processor will start playing the music.
End Music Notification
You provide the processor with a pointer to a function that it will call when the music data has been processed. Nice processors will call the function early so there will be no gaps in the sounds while reloading.
All of this is platform dependent and may not be standard across platforms.
Hope this helps.
This is quite a vast area, and, depending on exactly what you want to do, potentially very difficult.
You don't give much away by saying your project is "music based".
Is it a musical score typesetting program?
Is it processing audio?
Is it filtering MIDI data?
Is it sequencing MIDI data?
Is it generating audio from MIDI data
Does it only perform playback?
Does it need to operate in a real time environment?
Your question though hints at real time operation, so in that case...
The general rule when working in a real time environment is don't do anything which may block the real time thread. This includes:
Calling free/malloc/calloc/etc (dynamic memory allocation/deallocation).
File I/O.any
Use of spinlocks/semaphores/mutexes upon threads.
Calls to GUI code.
Calls to printf.
Bearing these considerations in mind for a real time music application, you're going to have to learn how to do multi-threading in C and how to pass data from the UI/GUI thread to the real time thread WITHOUT breaking ANY of the above restrictions.
For an open source real time audio (and MIDI) (routing) server take a look at http://jackaudio.org
gettimeofday() is the best for wall clock time. getrusage() is the best for CPU time, although it may not be portable. clock() is more portable for CPU timing, but it may have integer overflow.
This is pretty system-dependent. What OS are you using?
You can take a look at gettimeofday() for fairly high granularity. It should work ok if you just need to read time once in awhile.
SIGALRM/setitimer can be used to receive an interrupt periodically. Additionally, some systems have higher level libraries for dealing with time.