I'm working on an audio application, written in C. I need to provide live audio playback under Windows. I need to decide which audio API to use. I'm planning to use the basic waveOut API, but I wanted to check to see what the community here recommends.
I want code that will Just Work on any recent version of Windows, with no need to install libraries; and I want minimal latency.
I don't need or want any "effects", I just need to faithfully play whatever wave samples the application generates.
My understanding is that most of the professional audio applications on Windows use ASIO, which gives excellent low latency, but I don't want ASIO because I want my code to Just Work and most people don't have ASIO pre-installed on their computers. (At a later date I may go back and also add ASIO as an option, but I'm going for the most general solution first.)
Is there anything out there that would be better than waveOut for my purposes, or is that the best choice?
It depends on what you are trying to do. The basic waveOut audio API is better for streaming audio. It lets you queue up several buffers and have them automatically played in succession. But if audio is playing and you want to change it, or add something to it, that's relatively hard.
DirectX audio is better for event based audio. You can have several things playing at the same time without having to do the mixing yourself. You can add or remove little pieces of audio easily - like playing a sound when the user pulls the trigger on their gun. But streaming (i.e. playing 1 buffer after another) is harder.
waveOut is designed to facilitate playing audio that is constant, like a .mp3 file. DirectX is designed for audio that is intermittent, like feedback in a game.
ASIO is like the worst of waveOut and DirectX in terms of difficulty of programming, and it's not that stable. Applications typically can't share the audio device. However, it gives you the lowest latency access to that audio hardware. ASIO also gives you a way to synchronize playback on multiple devices.
If you don't need to be able to change what is going to be played right before it is played, and you don't need to synchronize multiple devices, then you don't need ASIO.
in addition to the options mentioned by John Knoeller, there is WASAPI which allows for much lower latencies than WaveOut, but unfortunately is only available from Windows Vista onwards.
At the time I asked this question, I wrote streaming code using the waveOut and waveIn APIs. Since then, I have discovered a useful library:
PortAudio
http://www.portaudio.com/
PortAudio is free software with a commercial-friendly license. If you write your code to call PortAudio it should be able to work with waveOut devices but also with ASIO devices under Windows; it can be then recompiled for Linux and should work with ALSA devices; and it can then be recompiled for the Mac and should work with CoreAudio devices. I haven't tested the Mac part but my project is working great with Windows and Linux.
Having written a DirectSound streaming application myself, I certainly recommend it for low-latency and ease of use. Also, it enables you to set a higher quality format for playback on legacy editions of Windows.
Related
I'm looking for a simple-ish library for outputting audio. I'd like it to meet these criteria:
Licensed under LPGL/zlib/MIT or something similar – i'm going to use it in an indie commercial application and i don't have the money for a license.
Written in C, but C++ is fine.
Cross-platform (Windows, Linux, maybe OSX)
Able to read from some sort of audio file (i'd prefer WAV or OGG but i will gladly use less popular formats if need be) in memory (i've seen the use of a memfile struct and user-defined I/O callbacks). I need the file to be in memory because i put all my resources into a .zip archive, and i use another library to load those archived files into memory.
Supports playing multiple sounds at the same time, having a max of 8 or so is ok.
I'd really like to either have the source code or a static library (MinGW/GCC lib???.a), but if nothing else is available i will use a shared library.
I must have come accross two dozen different audio libraries in my search, all of which haven't quite met these criteria...
I would recommend PortAudio + libsndfile. Very popular combo, meets your requirements. Used by many other software applications including audacity.
Some of the candidates that immediately spring to my mind are:
SDL (there is a tutorial that demonstrates how to play a .wav format sound)
libav
ffmpeg
libao
OpenAL Soft
Jack Audio
You may have already looked at these and eliminated them, though. Can you give some more detail about the libraries that you have eliminated from consideration and why? This will help narrow down our recommendations.
You might want to look into SDL and SDL_mixer. Here is a good tutorial.
I've used SDL_mixer and it makes it easy to play background sounds or music and play multiple simultaneous sounds without having a need to write your own sound sample mixer.
I ended up using PortAudio (very low-level, flexible license) and wrote a mixer myself. See this topic i made on the C++ forums for some other people's tips on writing a custom mixer. It's not hard at all, really; i'm surprised that there are so many mixer libraries out there. For a breakdown of the WAV format (ready-to-stream raw audio data with a 44-byte header) see this.
I've got a need to write a Linux application that does the following:
1- Continuously play a WAV file in the background. So the entire
time the application is running this background music plays.
2- Be able to play short sounds when certain events happen while the background music continues to play.
What is required to mix in the additional event sounds when they happen with the background music so that both are heard at the same time?
I've never written Linux sound code, so this is ALL new to me. I'm assuming that I will need to write to the ALSA API? Or some other library that will facilitate this?
If somebody could provide sample code to get me started I would greatly appreciate it. After a few days I will create a bounty and provide a good deal of reputation for sample code that does what is needed.
You usually don't want to use ALSA API directly. It's hard to use, and not really portable (since ALSA is specific to Linux).
If you are using some specific libraries in your application (like Qt or something like that), there may be already a counter-part sound library for playing sounds.
If you are looking for a good, general-use sound library, I suggest you take a look at SDL. It's quite nice, small and portable; very popular for games. They have quite a nice example code on their site to get you started.
For the part of playing sounds, one library that I used which is easy to learn, use and has a good example in its documentation is fmod. The documentation that comes with the download has a very easy to understand example which you can modify and get your sounds played very quickly.
I am looking for a modern system to do some bare bones Assembly programming (for fun/learning) that does not have the legacy burden of x86 platforms (where you still have to deal with BIOS, switching to protected mode, VESA horrors to be able to output pixels to the screen in modern resolutions/colordepths etc.). Do such systems even exist? I suspect it is not even possible today to do low-level graphics programming without dealing with proprietary hardware.
qemu is likely what you want if you dont want to have to build that stuff in. You wont get as much visibility as to what is going on in the guts of it.
For hardware, beagleboard (dont get the old one get the new one with reasonable connectors, etc), or the open-rd board. I was disappointed with the plug computer thing. The hawkboard I like better than the beagleboard, but am concerned about the big banner about a pcb design problem. The raspberry pi will be out at some point and will also provide what you are looking for. Note that for beagleboard, etc, you dont have to run linux or anything like that, you can write your own binary and xmodem it over or use the network and then just run it, not a problem at all.
The stellaris eval boards all/most have oled displays, monochrome and small but graphics, not sure how much you were after.
earth-lcd used to have an arm based board with a decent sized panel on it.
there is of course the gameboy advance and the nintendo ds. flash/developer cartridges are under $20. the gba is better to start with IMO, as the nds is like two gbas competing for shared resources and a little confusing. with a ez flash cartridge (open source software to program), was easy to put a bootloader on the gba and for like another $20 create a serial cable, I have a serial based bootloader for loading the programs. If you have an interest in this path start with the visual boy advance emulator to get your feet wet and see how you feel about the platform.
If you go to sparkfun.com there are likely a number of boards that either already have lcd connectors that you would mate up with a display or definitely displays and breakout boards that you could connect to a number of microcontroller development boards. Other than the insanely painful blue leds, and the implication that there is 64KB (there is but non-linear 32KB+16+16) the mbed board is nice, up to 100mhz, cortex-m3. I have some mbed samples at github as well that walk you through building an arm binary too boot an arm from flash for those that have not done it (and want to learn that rather than call some apis in a sandbox).
the armmite pro and the maple (sparkfun) are arm based arduino footprint platforms, so for example you can get the color lcd shield or the gameduino
There is the open pandora project. I was quite dissappointed with the experience, after over a year paid another fee to get the unit and it failed within a few minutes. Sent it back and I need to check my credit card statement, maybe we took the return and give it to someone who wants it path. I have used the gamepark gp32 and gpx2, but not the wiz, the gpx2 was fine other than some memory I/O problem in the chip that caused chaotic timing. the thing would run just fine but memory performance was all over the map and non-deterministic. the gp32 is not what you are looking for but the gpx2 might be, finding connectors for a serial cable might be more difficult now that the cell phone cable folks used to cut up is not as readily available.
gen 1 ipod nanos can still be had easily, as well as the older gen ipod classics. easy to homebrew, the lcd panels are easy to get at. grayscale only, maybe only black and white I dont remember. All the programming info is had from the ipodlinux folks.
I have not tried it yet but the barns and noble folks are homebrew friendly or as friendly as anyone on that scale has been so far. the nook color can easily be turned into a generic android device, so I assume that also means you could develop homebrew on the metal, not sure though, have not studied it.
You might look at always innovating, my experience with them was similar to the open pandora folks. These folks started with a modified beagleboard in a box with a display and batteries, then added a couple more products, any one of them should be very open, and homebrew friendly so you can write whatever level you want, boot and run on the metal, no problem. For the original product it was one of those wait for several months things.
I am hoping the raspberry pi becomes the next beagleboard but better.
BTW all hardware is proprietary, it is just a matter of whether they choose to provide programming information or not. vesa came about because no two vendors did it the same way, and that has not changed, you have to still read the dataseets and programmers reference manuals. But as you can see above I have only scratched the surface, and covered the sub or close to $100 items. If you are willing to pay in the thousands of dollars that greatly opens the door to graphics based development platforms that are well documented and relatively sandbox free. many are arm based since arm is the choice for phones, etc and these are phone-like, tablet-like, eval platforms.
The Android emulator is such a beast; it runs a linux kernel and driver stack (including /dev/fb) that one can log into via the android debugger bridge, and run (statically linked) arm-linux-eabi applications. Framebuffer access is possible; see example.
The meta-question rather is, what do you mean by "low-level" graphics programming; no emulator is going to expose all the register and chip state complexity that's behind a modern graphics chip pipeline. But simple framebuffer contents manipulation (pixel buffer access) is surely simple enough, as is experimenting with software rendering in ARM assembly.
Of course, things that you can do with the Android emulator you can also do with cheap physical ARM hardware, like the beagleboard and similar. Real complexity only begins when you want to access "advanced" things - that's anything accelerated functionality beyond just reading/writing framebuffer contents.
New Answer
I recently came across this while looking for emulators to run NetBSD on, but there's a project called GXemul that provides a full-system computer architecture emulation with support for a variety of virtual devices and CPUs. The primary and most up-to-date core looks to be MIPS-based, but it also lists support for emulating the ARM architecture. It even includes an integrated debugger and it sounds like you can just assemble your code into a raw binary with some bootstrapping code and boot it as a kernel inside the emulator from the commandline.
Previous Answer
This isn't an emulator, but if you're interested in having a complete, ARM-based computer that you can develop whatever you want on that doesn't cost much, you should keep an eye on the Raspberry Pi project. They're very close to selling a complete, tiny, low-power ARM-based computer for $25 a piece. It has USB ports, ethernet, video out, and an SD card reader, and can boot Linux, although in your case you'd probably want to boot your own code and access the hardware directly.
EDIT: Looks like Erik already mentioned it.
I was wondering if its possible to use a sound card , and produce various notes from it using assembly level or C programming language .
See this SO answer Streaming Data to Sound Card Using C on Windows
which points you towards http://www.portaudio.com/
PortAudio is a free, cross-platform, open-source, audio I/O library. It lets you write simple audio programs in 'C' or C++ that will compile and run on many platforms including Windows, Macintosh OS X, and Unix (OSS/ALSA). It is intended to promote the exchange of audio software between developers on different platforms. Many applications use PortAudio for Audio I/O.
PortAudio provides a very simple API for recording and/or playing sound using a simple callback function or a blocking read/write interface. Example programs are included that play sine waves, process audio input (guitar fuzz), record and playback audio, list available audio devices, etc.
Yes, it is possible. Implementation of that will greatly depend on the system you will be coding for.
You're generally will have a choice to work with DAC (digital to analog converter) output, or, possible, accessing MIDI.
I'm no expert in sound generation, but... Of course it's possible. Something is needed to make calls to the sound card at some point in any application that uses audio, after all.
However, in almost all cases it's better to make calls to an API, and let the existing sound card driver of the system do all the busywork. Much more portable (...to an extent, at least), and much easier.
http://www.linux.com/archive/feature/113775 might have some good info. For Windows Vista/7, you can check out http://msdn.microsoft.com/en-us/library/dd370784%28v=vs.85%29.aspx.
Oh, and in many cases you'd be better off using an existing software library that can produce the notes rather than trying to generate the waveforms yourself. (See Fredrik's answer.)
Both has bindings for C, both can play various formats.
Which one is more superior? in terms of simplicity, performance, overhead and memory footprint.
Also which one is better at handling multiple streams?
I have not programmed with either of those, but I believe that OpenAL has been designed to render and output multiple-channel audio for games, with real-time performance as a requirement.
libSoX is more for input and output from audio files, as well as for format conversions. There are lots of plugins but AFAIK it has not been designed for real-time audio output. It seems significantly simpler to use, though.
You might also want to have a look at libsndfile.
What exactly is it that you want to do?
While I have never used OpenAL, I've heard a lot of bad things about it that make it sound unprofessional and basically a dead end. From Wikipedia:
OpenAL was originally developed by Loki Software in order to help them in their business of porting Windows games to Linux. After the demise of Loki, the project was maintained for a time by the free software/open source community, and implemented on NVIDIA nForce sound cards and motherboards. It is now hosted (and largely developed) by Creative Technology with on-going support from Apple, Blue Ripple Sound, and free software/open source enthusiasts.
While the OpenAL charter says that there will be an "Architecture Review Board" (ARB) modeled on the OpenGL ARB, no such organization has ever been formed and the OpenAL specification is generally handled and discussed via email on its public mailing list.
Since 1.1, the implementation by Creative has turned proprietary, with the last releases in free licenses still accessible through the project's subversion. However, OpenAL Soft is a widespread Open Source alternative.
There was also an issue with it messing up the state of the calling application; I believe just linking it caused some global constructors to run before the invocation of main in a way that altered the program's initial environment, and broke some programs (MPlayer perhaps?). It's unclear to me whether this issue was ever fixed, but it screams bad library and I would be skeptical of ever trusting a library historically contained such abuses.