I'm not actually well versed in C++ or SDL_Mixer, but I'm asking this question anyway on behalf on the Doom community. Put simply, nobody writing Doom source ports can seem to figure out how to control normal sound volume and MIDI sound volume independently using SDL_Mixer on Windows Vista or 7. I'll let James Haley, author of Eternity Engine, put it in his own words:
Seems the concept of independent volume for native MIDI doesn't exist under Windows Vista or 7, as using MIDI volume sliders in any application that has them (including most games that use SDL_mixer) also affects the volume of digital sound output. This makes attempting to adjust the relative volume of music for comfort impossible.
Has anybody found any workarounds for this? I'm guessing it's unlikely given how Microsoft seems to have skimped throughout the OS on any way to control the volume of individual sound devices separately.
I've heard of various workarounds all involving a Timidity driver, but this requires the user go above and beyond simply installing the game on his system. The only port that I know of that definitively fixes this issue is ZDoom, but it uses the GPL-incompatible FModEx and is thus not a suitable solution.
If you want some code to look at, Chocolate Doom is perhaps the easiest Doom source port to grok and you can grab its source here.
Any suggestions on other open-source sound and music libraries would be welcome as well.
A solution would be to ship with a FluidSynth-enabled SDL_mixer. You would also need to ship a SoundFont2 file to go with it. Fortunately, there are free SF2's out there, and some are even optimized for Doom's MIDI files. Licenses shouldn't be a problem, since SoundFonts are assets, not code.
You then load the SF2 using Mix_SetSoundFonts().
You may want to look at different MIDI libraries outside of SDL.
http://wildmidi.sourceforge.net/
http://sourceforge.net/apps/trac/fluidsynth/
http://timidity.sourceforge.net
I am maintaining a similar game port (Descent 2), and I have come across the same problem. Afaik there is no solution for it when using SDL_mixer. A cure to avoid sound being muted when turning off midi music I have found is to retrieve a handle to a temporary midi device, set the midi volume to max and then close the temporary device again.
For the longest time, the only solution we found was to use something like PortMIDI. However, Quasar of Eternity Engine fame has come across a neat solution:
http://www.doomworld.com/vb/showthread.php?s=&postid=1124981#post1124981
He essentially puts SDL_Mixer into its own process and controls it with RPC. Very clever.
So one problem with the previous answer I gave was that sometimes the MIDI subprocess did not behave itself, and would break or stop working in strange ways. Eternity's specific implementation used IDL, and I personally re-implemented it using pipes, but the subprocess itself was a bug magnet.
Thankfully, another answer was figured out rather recently. You can simply bypass SDL_Mixer entirely and deal with Windows' native MIDI support directly, which turns out to not require a ton of code once you know what you're doing.
https://github.com/chocolate-doom/chocolate-doom/blob/master/src/i_winmusic.c
You can also implement this sort of idea with PortMIDI and get the benefit of being able to communicate with external MIDI devices as well.
https://github.com/odamex/odamex/blob/stable/client/sdl/i_musicsystem_portmidi.cpp
Related
Is there a Windows standard way to do things such as "start fan", "decrease speed" or the like, from C/C++?
I have a suspicion it might be ACPI, but I am a frail mortal and cannot read that kind of documentation.
Edit: e.g. Windows 7 lets you select in your power plan options such as "passive cooling" (only when things get hot?) vs. "active cooling" (keep the CPU proactively cool?). It seems the OS does have a way to control the fan generically.
I am at the moment working on a project that, among other things, controls the computer fans. Basically, the fans are controlled by the superIO chip of your computer. We access the chip directly using port-mapped IO, and from there we can get to the logical fan device. Using port-mapped IO requires the code to run in kernel mode, but windows does not supply any drivers for generic port IO (with good reason, since it is a very powerful tool), so we wrote our own driver, and used that.
If you want to go down this route, you basically need knowledge in two areas: driver development and how to access and interpret superIO chip information. When we started the project, we didn't know anything in either of these areas, so it has been learning by browsing, reading and finally doing. To gain the knowledge, we have been especially helped by looking at these links:
The WDK, which is the Windows Driver Kit. You need this to compile any driver you write for windows, With it comes a whole lot of source code for example drivers, including a driver for general port-mapped IO, called portio.
WinIO has source code for a driver in C, a dll in C that programmatically installs and loads that driver, and some C# code for a GUI, that loads the dll and reads/writes to the ports. The driver is very similar to the one in portio.
lm-sensors is a linux project, that, among other things, detects your superIO chip. /prog/detect/sensors-detect is the perl program, that does the detecting, and we have spent some time going through the code to see how to interface with a superIO chip.
When we were going through the lm-sensors code, it was very nice to have tools like RapidDriver and RW-everything, since they allowed us to simulate a run of sensors-detect. The latter is the more powerful, and is very helpful in visualising the IO space, while the former provides easier access to some operations which map better to the ones in sensors-detect (read/write byte to port)
Finally, you need to find the datasheet of your superIO chip. From the examples, that I have seen, the environment controllers of each chip provide similar functionality (r/w fan speed, read temperature, read chip voltage), but vary in what registers you have to write to in order to get to this functionality. This place has had all the datasheets, we have needed so far.
If you want something real quick to just lower fans to a level where you know things won't overheat, there's the speedfan program to do so. Figuring out how to configure it in the early versions to automatically lower fans to 50% on computer startup was so painful that my first approach was to simply byte-patch it to start the only superio managed fan I had at lower speed. The newer versions are still bit tough but it's doable - there's a graphical slider system that looks like audio equalizer except that the x axis is temp and y is fan speed. You drag them down one by one. After you figure out how to get manual control for the fan you want, this is next step.
There's a project to monitor hardware (like fans) with C#:
http://code.google.com/p/open-hardware-monitor/
I haven't extensively looked at it, but the source code and use of WinRing0.sys atleast gives the impression that if you know what fan controller you have and have the datasheet, it should be modifiable to also set values instead of just getting them. I don't know what tool is suited (beside kernel debugger) to look at what Speedfan does, if you preferred to snoop around and imitate speedfan instead of looking at the datasheets and trying things out.
Yes, It would be ACPI, and to my knowledge windows doesn't give much/any control over that from user space. So you'd have to start mucking with drivers, which is nigh impossible on windows.
That said, google reveals there are a few open source windows libraries for this for specific hardware... so depending on your hardware you might be able to find something.
ACPI may or may not allow you to adjust the fan settings. Some BIOS implementations may not allow that control though -- they may force control depending on the BIOS/CMOS settings. One might be hard-pressed for a good use case where the BIOS control (even customized) is insufficient. I have come across situations where the BIOS control indeed was insufficient, but not for all possible motherboard platforms.
WIndows Management Instrumentation library (WMI) does provide a Win32_Fan Class and even a SetSpeed method. Alas, the docs say this is not implemented, so I guess it's not very helpful. But you may be able to control things by setting the power state.
I am working on a C++-based MIDI sending app and it's the first time I'm working with MIDI.
I chose the RtMidi library because it seems to be the most complete library around, but I'm open to suggestions.
The OS that I'm working on is Windows 7 and I have an USB-MID interface installed and it's working with other programs (i.e. Roland UM-One).
Now I may be way off-track, but I'd expect that when you do a search for ports, it should show this device.
When compiling the example code for RtMidi i get no ports; in or out.
What am I missing?
Do i need to open a virtual port?
This is also for others experiencing a similar issue as well:-
When I first started using RtMIDI, if you don't specify (on OSX at least) a macro define for the target system, the example code by default uses a dummy MIDI device, and this will have no MIDI ports.
Once I had specified MAC_OSX_CORE, then RtMIDI used the correct architecture and returned the MIDI devices on my system as expected. Perhaps you have to do something similar for your system - check the docs under "Compiling":
http://www.music.mcgill.ca/~gary/rtmidi/index.html#compiling
I've worked briefly with RtMidi and it is, as you stated, a rather complete library. However, when working with MIDI devices, you have to take the specific issues of this type of devices into account.
Another thing is that cheap USB-MIDI adapters often simply refuse to work with some applications "just because". They are very simple inside, yet apparently chinese manufacturers are still able to make malfunctioning devices.
If you're using unmodified, example code, and it's not showing your device, I'll first ensure all other apps that might be using it are closed, then try again. Creating a virtual interface is also a nice idea; I personally use freeware LoopBe1 for it. If it will show the virtual, but not the real interface, then the problem is with device itself. In that case you might want to experiment with different drivers or simply plugging it into a different port.
If it doesn't show any device, neither real nor virtual, then I strongly suspect there's something wrong in the way you build/run the application.
I am using Windows 7 and developing a chat-like application with Visual Studio 2010. I am looking for an EASY way of capturing audio from a microphone (or rather, from the default recording device), collect the buffer from said input, and send it over a socket. I've seen DirectX solutions recommended, but from my research that is quite the opposite of simple. 5000 lines of sample code for a simple capture/save file program? That simply doesn't work for me (and yes, that was an official sample provided with the SDK).
Anyway, I don't need it to be cross-platform, and I would really prefer something that already comes with Windows, though I don't mind installing a library as long as it doesn't take longer than writing the hardware drivers from scratch to figure it out (exaggeration). I've heard of this waveInOpen function, but oddly enough I cannot find any demos on how to use it. If anyone has an idea or a link to some sample code, I would greatly appreciate it. Thanks everyone for your time!
P.S. I can figure out the networking part myself. I just need access to the raw audio data buffer.
If you're doing the sockets yourself try checking out:
http://www.techmind.org/wave/
http://www.bcbjournal.com/articles/vol2/9810/Low-level_wave_audio__part_3.htm
http://www.relisoft.com/freeware/recorder.html
I enjoyed all of them but the last one, but then again, you might find it far more helpful.
How does one begin writing drivers for Windows? Is there some sort of official DDK "Hello World" example out there?
While I'm sure it will be way above my head at first, eventually I would like to create a simple MIDI driver, much like the Maple Virtual MIDI Cable where the MIDI messages come from a user application rather than a physical device.
(The trouble with using the off-the-shelf MIDI loopback drivers is that the existence of an input and output end is often confusing for the user. My application generates MIDI output that gets sent to the MIDI input of other programs, so if I could create a fake driver that connects to my program rather than hardware, it would eliminate this confusion.)
Thank you for your time.
The WDK docs are reference material, they won't teach you how to get started. Essential are the sample code included with the WDK, there's lots of it and you can often find something that resembles the kind of driver you want to create. A generic filter driver is available in the src\kmdf\toaster\filter directory, I think that's what you'd need if I understand your goal properly.
Walter Oney's books are essential to learn important concepts, strongly recommended. I keep running into osronline.com as a web site that strongly focuses on driver development, with forums. You typically won't find much help here, it is a rather specialized kind of coding.
You could take a look at my virtualMIDI-driver:
www.tobias-erichsen.de/virtualMIDI.html
This one does exactly what your are looking for.
Tobias
I'm developing a musical game, it's like a singstar but instead of singing, you have to play the recorder. It's called oFlute, and it's still in early development stage.
In the game, I capture the microphone input, then run a simple FFT analysis and compare the results to typical recorder's frequencies, thus getting the played note.
At the beginning, the audio library I was using was RtAudio, but I don't remember why I switched to PortAudio, which is what I'm currently using. The problem is that, from time to time, either it crashes randomly or stops capturing, like if there were no sound coming from the microphone.
My question is, what's the best option to capture microphone input on Linux? I just need to open, read, and close a flow of bytes from the microphone.
I've been reading this guide, and (un)surprisingly it says:
I don't think that PortAudio is very good API for Unix-like operating systems.
So, what do you recommend me?
PortAudio is a strange choice given the other options.
I would personally abstract away from everything and use GStreamer. Audio can be a horrible mess on Linux (speaking as a long term sufferer). Letting Gstreamer deal with that lets you forget about it, move along and not have to think about it again.
OpenAL is probably the most popular for game dev though and it should support most systems (although you will have "fun" getting it playing nice with PulseAudio).
I'd certainly make sure you're developing for the most popular setup (which is PulseAudio at the moment, I reckon) so you don't end up in a situation where you release and you're plunged into a pool of people moaning about the sound not working.
And don't listen to the nonsense about PulseAudio - it might be new and it might take up a few more resources than a barebones ALSA system but it's certainly not mired with latency issues. Asking people to remove it isn't an option with modern desktop distros as it's so tightly integrated (and useful too).