Audio Loopback Progress
by Demolishun · 12/30/2012 (3:59 pm) · 2 comments
Background:
This code has taken more than one rewrite to get my head around how it should operate. At the outset I created a monolithic design with little flexibility and more than one error in the code. I have been working to get my head around the thread safe constructs of T3D. There are some good examples in the code itself. There are also some helper classes that make working with mutexes and semaphores safer. Part of the confusion on my part was the C++ modifier "volatile". There seems to be some confusion as to how much this keyword helps you with threading. Mostly because there are platform/compiler specific differences for that particular modifier. My feelings on this issue is to avoid the modifier altogether to prevent platform specific code.
What does this do? WTH are you talking about?
Well, it takes data from the AudioLoopBack device on Windows (Vista and later). Then it processes that data to produce frequency magnitude data using FFT (Fast Fourier Transform). The magnitude data is customizable and has some sane defaults. This allows the game to track ANY sound being played on the computer and react to that sound in game. The idea is making it so a person can customize their game experience by selecting their own music sources played by programs outside the engine or within the engine.
Is that all?
Initially that was going to be all you could do with this. However, I am reworking the code to allow the functions to exist separate from the actual audio loopback capture. The idea is to allow the user to put any kind of data they want through the FFT function. It could be audio or anything else. Heck it could be stock ticker data if you wanted. This will provide the tools (in C++ and some limited support in TS) to say analyze a particular sound by tapping into the playback of a sound (will require C++ to accomplish this). If the freqs analyzed were setup to limit themselves to speech then you could theoretically have it control the animation of a character's mouth. The result would be automagic lip syncing. So it has the potential to allow animations to be synced to sounds or other sources of data.
What will it look like in code?
My hope is it will be a couple of console commands to control the loopback data capture. In addition there will be sim objects that will have access to the data returned and can further process the data. The functions will be FFT to start, but others could be added as needed. For instance, if you wanted to display the incoming waveform you just need the raw data. The data could in turn be sent over the network so other players can hear what you are playing. The possibilities would be there.
Cross platform?
To start, not completely. The loopback data capture API is unique to Windows. So for other platforms it will either be ignored, or implemented using the platform specific API. The other functions will be available though. That is one reason for not making this monolithic. Pieces can still be used outside of Windows.
Hurry up dang it!
Yep, it will get done soon. When I release this it will be a resource here at GG. If you use this and extend it please contribute back. Especially the cross platform support for the audio capture.
This code has taken more than one rewrite to get my head around how it should operate. At the outset I created a monolithic design with little flexibility and more than one error in the code. I have been working to get my head around the thread safe constructs of T3D. There are some good examples in the code itself. There are also some helper classes that make working with mutexes and semaphores safer. Part of the confusion on my part was the C++ modifier "volatile". There seems to be some confusion as to how much this keyword helps you with threading. Mostly because there are platform/compiler specific differences for that particular modifier. My feelings on this issue is to avoid the modifier altogether to prevent platform specific code.
What does this do? WTH are you talking about?
Well, it takes data from the AudioLoopBack device on Windows (Vista and later). Then it processes that data to produce frequency magnitude data using FFT (Fast Fourier Transform). The magnitude data is customizable and has some sane defaults. This allows the game to track ANY sound being played on the computer and react to that sound in game. The idea is making it so a person can customize their game experience by selecting their own music sources played by programs outside the engine or within the engine.
Is that all?
Initially that was going to be all you could do with this. However, I am reworking the code to allow the functions to exist separate from the actual audio loopback capture. The idea is to allow the user to put any kind of data they want through the FFT function. It could be audio or anything else. Heck it could be stock ticker data if you wanted. This will provide the tools (in C++ and some limited support in TS) to say analyze a particular sound by tapping into the playback of a sound (will require C++ to accomplish this). If the freqs analyzed were setup to limit themselves to speech then you could theoretically have it control the animation of a character's mouth. The result would be automagic lip syncing. So it has the potential to allow animations to be synced to sounds or other sources of data.
What will it look like in code?
My hope is it will be a couple of console commands to control the loopback data capture. In addition there will be sim objects that will have access to the data returned and can further process the data. The functions will be FFT to start, but others could be added as needed. For instance, if you wanted to display the incoming waveform you just need the raw data. The data could in turn be sent over the network so other players can hear what you are playing. The possibilities would be there.
Cross platform?
To start, not completely. The loopback data capture API is unique to Windows. So for other platforms it will either be ignored, or implemented using the platform specific API. The other functions will be available though. That is one reason for not making this monolithic. Pieces can still be used outside of Windows.
Hurry up dang it!
Yep, it will get done soon. When I release this it will be a resource here at GG. If you use this and extend it please contribute back. Especially the cross platform support for the audio capture.
About the author
I love programming, I love programming things that go click, whirr, boom.
#2
Haha! The examples in threading will be "an" example of threading. Not necessarily a "proper" example.
01/01/2013 (2:39 pm)
@dB,Haha! The examples in threading will be "an" example of threading. Not necessarily a "proper" example.
Torque Owner Daniel Buckmaster
Flat Chat