Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mysterycoder]

I fixed up the CMake build system.
The directory structure is the same, except it now supports having a "dependencies" folder. Or, if you don't want to use that, I've set it up so the CMake gui can configure the paths.
"dependencies" should rest at the same level as trunk and build:
build/
dependencies/
trunk/

I have the dependencies folder setup as follows:
dependencies/BoostPython/Include/boost (I left all the boost includes as "boost/blah.hpp" because I see everyone use it this way)
dependencies/BoostPython/Library
dependencies/Ogre/Include
dependencies/Ogre/Library
dependencies/PortAudio/Include
dependencies/PortAudio/Library
dependencies/StacklessPython/Include
dependencies/StacklessPython/Include/Stackless (I might combine the include and the include/stackless directories)
dependencies/StacklessPython/Library

Hopefully now it should compile a bit more nicely for ya, without you having to mess with the Visual Studio projects.

[mysterycoder]

Ah cool! I think I found it. I tried switching out my callback for the sine callback, and everything worked. I think there was a memory problem with the old callback or something and the debugger was hitting weird points because it's called specially. Though, I'm not entirely sure.

I'm going to add the wav codec and do a test, clean up the code, and commit.

Reading the documentation, it doesn't seem like opening up multiple streams is a commonly supported thing.  I'm thinking we'll have to put together some sort of rudimentary software mixer.

Btw, I get a slight click when the streams close, do you get the same?

[mysterycoder]

Just a thought while I'm working on this.
As far as I understand, for playing and recording sound you're supposed the same stream.
So when WGE starts, I'll open a single stream for both playing and recording. (I don't know if this will be a problem on 5.1 systems with only stereo recording)
I was thinking of making the playing api the same, having the audiomanager create audioclips using codecs, and reading data from an audioclip's ring buffer into the simple software mixer, which in turn, goes into the callback.
But, as I've never done recording on a computer before and since it's mainly applicable to your game  , how do you want the api for recording to look?

[pjcast]

Well, I have no preference yet as to what things should look like. I need to get more familiar with portaudio - it may not really be sufficient for the tasks at hand. I do know, though, what I will need will be that the recording stream has to be able output as quick as possible to the output buffer (of course, a configuration option - not everyone needs input going right out). This means that the data I would send to an FFT function would need to be buffered to some other queue (especially since there may not be enough of a buffer size captured in one callback to analyze). Other's may use the buffered input data to compress and send out through the network, for example. However, there may be a need for inline modification of the signal before being outputted (ie digital filters: doppler effects, reverb, etc).

I'm not sure what you mean by stereo recording - most all input is done via mono channels. There is one exception, the singstar USB mics actually comes across as a single stereo input (blue mic being left channel and red being right channel). I would like to support as many input channels as possible on the recording side.

There are some questions hanging on my mind still regards mostly to the ASIO backend:
* Does portaudio have any kind of support for 5.1+ sound audio
* Is there any kind of access to hardware channels (ie load a sample into a hardware buffer for quicker playback)

Anyway, I plan to look at that OpenAL software lib you mentioned and see what it entails.

[pjcast]

Hmm, looking at the portaudio samples, seems that it supports using multiple output channels (ie 5.1 +). I'm still not sure if it supports hardware buffer channels at all (ie OpenAL sources, fmod channels, etc). Not strictly needed, as mixing a few sources is not computationally expensive. But, would be nice. I downloaded openalsoft. It apears to have a directsound backend supported, maybe it might be worth adding an ASIO backend to it instead of trying to tie portaudio to it.

[pjcast]

I was looking at OpenAlsoft source.. and, It doesn't appear they do anything special for their source buffers. Looks like just standard memory buffers.. Though, I haven't looked much at how many DirectSound streams they are creating. Anyway, it looks like it might be fairly easy to write a new ASIO backend for that.

[mysterycoder]

Yup, OpenAlSoft doesn't use hardware buffers, that was the goal initially, but it fell through. It's a purely software mixer.

If we are going to add such a backend, and we want it to be integrated upstream, I think we should talk to the author beforehand. I recall reading about a pulseaudio backend which was written, but wasn't integrated because the author of OpenAlSoft disagreed with the idea of pulseaudio, or something like that 

To be honest, even though I'm all for learning new things, I was a little worried about having to mix audio, write sample converters, reverb effects, and 3D positional sound.
So, even though I'm up for trying this with Portaudio (I already was working on a basic audiomanager), I'm also very cool with sticking with OpenAL (Already written, can still use sound while developing an ASIO backend).

[pjcast]

Well, mixing channels is not very difficult - just have to watch out for clipping. But, yeah, we can probably just use the OpenALSoft lib and add an ASIO backend (regardless of whether it gets added in officially) - at least, i need low latency sound for what I wish to accomplish Though, I haven't used a capture/record interface with OpenAL before, not sure where to start there (looking at the code, some of the backends have start capture or some such, but none seem implemented).

[mysterycoder]

Oh, I was under the assumption that it is quite difficult to mix sounds, it's been rather hard for me to find information on audio on the internet. (Any good resources btw? I know the book "Audio Anecdotes" is supposed to be good")

Fortunately, audio capture is present in the OpenAl 1.1 specification and is in creative's windows implementation. Hopefully it will be quite easy to add in because it is designed for it in the specification. I also imagine it was in the original sample implementation.

I know you're quite busy, so if you don't have the time to implement ASIO and FFMpeg I would be perfectly content doing it. But, if you do have the time (you ARE the author of the FFMpeg plugin for Ogre  ), what features do you think I should focus on? I'm not doing anything particular with the engine right now, so it's really up to your discretion.

[pjcast]

I don't know of any good links. However, mixing channels is simply adding two waveforms together and reducing the output a bit to account for clipping. The hard part, is trying to synchronize multiple channels to some clock (like for video sync).

However, if we can avoid getting that low level, it would be a good thing. As for OpenAL Soft + ASIO, I'm a little concerned about buffer size. ASIO can handle relatively tiny buffers, while OpenAL has the tendency to stop playing audio if it encounters buffer underruns (not enough data to play). Might be difficult getting the two to mesh well... I've only found a handful of threads on the mailing list about such integration. Might be worth asking there if they think the two could be added together for very low latency audio in/out.

As for ffmpeg, I can handle that decoding aspect - or you can if you want. It is not that difficult to work with. Syncing audio and video can be a little tricky, but doable. The hardest part about ffmpeg is getting it built on Windows Or, if you want to look at creating an ASIO backend for OpenAL soft that would rock. Either way, its up to you - one does not depend on the other (ie ffmpeg does not need ASIO nor does ASIO need ffmpeg).

[mysterycoder]

I have yet to get a codec working, so I think I'll choose ffmpeg 
Now, I was thinking, should there be two codecs?, one for sound and one for video? or simply one?
I'm going to download the ffmpeg plugin for Ogre and use that as a reference.

[pjcast]

Not sure what you mean by "yet to get a codec to work". The codec system can be modified to support file formats - so that by registering mpg, mpeg, mp2, etc it would go to ffmpeg (registered) decoder.

In regards to the old plugin, I would take that with a grain of salt The ffmpeg API has likely changed much since then. FFmpeg comes with an SDL player example which is what I based the plugin off of. I would suggest trying to get that working (requires you get SDL, Mingw, Msys, ffmpeg source, et al).

[mysterycoder]

Ah, I just meant that I, personally, haven't written a working codec yet, having already tried FLAC, OggFLAC, and a long time ago, WAV. So it'll be a first for me
I see what you mean about the codec system, I definitely see that working.
And ffmpeg is quite the feat on windows, maybe I'll write it on Linux first (Naw, I'm sure I'll get gcc working with it eventually )

[pjcast]

So, after another look, I see that the OpenAL soft implementation only has capturing for the WinMM backend (not DirectSound) backend. Not a big deal, however... I'm not liking the method of capturing. It relies on a polling method. Right now I see (for WinMM system):

There is a WinMM callback that gets the samples and adds it to a small buffer, it then signals (awakens) a processing thread
The processing thread will try to write to another buffer (and if the buffer is to full, it will overwrite some of the data)
Then, you are required to call a method to read capture samples (and you specify how many samples you want).

Now, what I find wrong with this method is:
* Too many buffers being copied, and one too many layers - both which will increase latency dramatically making the gains from ASIO vastly reduced (at last in my eyes, would have to run real tests to know for sure).
* Polling method is a waste of CPU time
* Loss of data if not polled fast enough not that acceptable to me

This, however, also goes along with how you stream data with openAL, you are required to constantly query for empty buffers, and then manually push data to them.

Personally, I don't like either method. I prefer the method of fmod (and Portaudio), where for playback, it queries you for data when it runs out and needs to play more data. Or, in the case of capturing, you get a callback event with the bytes that came in and are ready for processing. This greatly reduces the complexities of user code, and also reduces the chance of audio overflow/underlows.

I wonder, since this OpenAL Soft is LGPL, if we could take the mixing code, effects, positional things, and integrate a new API into it. One that makes heavy use of callbacks for audio data.

[mysterycoder]

Heh, perfectly cool with me.   I'm always up for a challenge.

Just a quick update: The WavCodec is working well with OpenAlSoft, plays a song fine. I got ffmpeg compiling and linking on windows. Also, the FFMpegCodec is definitely in the works.