next »

[Klaim]

I'm still interested in using this library in my game, but it seem that it will not be ready for production use (specific repository, clean interface) in the coming months? Or will it?

[Evan Balster]

Most likely it will begin moving rapidly in that direction soon.  (I'm waiting on something.)  Priorities will include better handling of drivers, maintaining a clean but transparent pipeline, and improved featureset for 3D games.  I may add additional abstraction layers that mimic the fixed-function behavior of OpenAL/FMOD, but this is a low priority.  The system is designed to be most useful for larger projects that want advanced audio functionality and deep control, while keeping basic operations like loading and playing sound files to one or two function calls.

What are your criteria for production-readiness?  The engine is currently being used in SoundSelf and several of my other projects; it works quite well for a small (<16) number of audio streams with a few effects each on PC/Mac.  In my view the biggest things currently lacking are a stable audio buffer class and a better API for highpass/lowpass filtering.

[Klaim]

The system is designed to be most useful for larger projects that want advanced audio functionality and deep control, while keeping basic operations like loading and playing sound files to one or two function calls.

As my game is partially about hacking opponent's outputs, I guess it match this description.

What are your criteria for production-readiness?  The engine is currently being used in SoundSelf and several of my other projects; it works quite well for a small (<16) number of audio streams with a few effects each on PC/Mac.  In my view the biggest things currently lacking are a stable audio buffer class and a better API for highpass/lowpass filtering.

Well first, a library repository would be best to allow me to upgrade this library code into my game repository only when I want, and easily, by a simple erase-copy-paste operation.
Which means the library should be provided as a library-only repository or archive. My understanding is that the current source code is only provided into the archive in the first message of this thread? Or did I miss something?

For other features, well mostly stability. Thread-safety would be best but we already had this discussion. In my game-specific engine I can manage a specific thread for audio which should be "monitored" through other facilities to keep the audio system thread-safe. So I'll be good.

I don't need advanced features immediately. I'm setting up the graphic code right now, and will be doing this for two month I think. I could spend some time just putting some ambiant music and basic sounds before I finish graphic code but that's all.
I know I will need some looping "noise" sounds, so if there is a way to generate them on-the-fly for cheap, it would be excellent in my context.

After these two months I'll have a better idea of the advanced features I need but from now all I see is: 3D position of audio source, audio deformations (both output and sources) and merging the output with procedural noise.

What do you think?

[Evan Balster]

All that's quite manageable.  The main thing keeping multithreaded audio control from being simple is the fact that the current system uses only one (framerate-based) scheduler, which will change down the line but is a low priority.

Filtering, mixing, and synthesis of audio are all very easy and I'll be providing DSPs for all of these things.  What I don't provide is relatively easy to write from scratch, assuming a basic understanding of DSP.  White and pink noise will definitely be in the core library, though.

My timeline for this project will have me releasing a new version probably by the end of this month before dramatically stepping things up.  I can't say exactly what I'll be prioritizing, but it seems likely that it will coincide well with your development schedule.

EDIT:  Keep in mind I'm not necessarily going to maintain backwards code compatibility before version 1.0.  The API is likely to get a few facelifts.

[Klaim]

My timeline for this project will have me releasing a new version probably by the end of this month before dramatically stepping things up.  I can't say exactly what I'll be prioritizing, but it seems likely that it will coincide well with your development schedule.

Indeed. Let's get back to this once this is done then.

EDIT:  Keep in mind I'm not necessarily going to maintain backwards code compatibility before version 1.0.  The API is likely to get a few facelifts.

Classic library versionning, not problem. I'll just update only when needed and assume it will cost me tons of changes, until 1.0. Hopefully the audio code should be well isolated in my code so it will not take that much time.

[Evan Balster]

Version 0.2.0 released.  Lots of additions and improvements; this one's much more viable for production-level use.  Hahaha foot in mouth.

Download here.

Extensive documentation here.

Changelog here.

Spent 10 solid hours on this today, mostly writing docs.  Completely trashed.  Going to bed.

[InfiniteStateMachine]

Just tried it out and it compiles with my project fine but when I create a Audio object from the getting started tutorial I get a null reference crash. Here's my console log:

I've only tried doing a debug build so far (used the debug libs).

 

Code:

before paHostApiInitializers[0].
after paHostApiInitializers[0].
before paHostApiInitializers[1].
Cannot create Capture for Primary Sound Capture Driver. Result = 0x88780078
PA - PlatformId = 0x2
PA - MajorVersion = 0x6
PA - MinorVersion = 0x1
PA - PlatformId = 0x2
PA - MajorVersion = 0x6
PA - MinorVersion = 0x1
PA - PlatformId = 0x2
PA - MajorVersion = 0x6
PA - MinorVersion = 0x1
after paHostApiInitializers[1].
before paHostApiInitializers[2].
after paHostApiInitializers[2].
before paHostApiInitializers[3].
WASAPI: device idx: 00
WASAPI: ---------------
WASAPI:0| name[Speakers (2- High Definition Audio Device)]
WASAPI:0| form-factor[1]
WASAPI:0| def.SR[44100] max.CH[2] latency{hi[0.010159] lo[0.003000]}
WASAPI: device idx: 01
WASAPI: ---------------
WASAPI:1| name[Digital Audio (S/PDIF) (2- High Definition Audio Device)]
WASAPI:1| form-factor[8]
WASAPI:1| def.SR[44100] max.CH[2] latency{hi[0.010159] lo[0.003000]}
WASAPI: initialized ok
after paHostApiInitializers[3].
before paHostApiInitializers[4].
Setup called
Enum called
noError = 0
Enum called
noError = 0
Enum called
noError = 1
Device 2 has render alias
Enum called
noError = 0
Enum called
noError = 1
Device 4 has render alias
Enum called
noError = 0
Enum called
Interfaces found: 2
Device 2 has render alias
Interface 2, Name: HD Audio Headphone/Speakers
Creating pin 0:
No standard streaming
Creating pin 1:
Not source/sink
Filter NOT created
Device 4 has render alias
Interface 4, Name: HD Audio SPDIF out
Creating pin 0:
No standard streaming
Creating pin 1:
Not source/sink
Filter NOT created
after paHostApiInitializers[4].
AVAILABLE AUDIO APIs: 5
  API 0 'MME' (*) with 3 devices:
  |- 44100  2o     `Microsoft Sound Mapper - Output'
  |- 44100 +8o     `Speakers (2- High Definition Au'
  |- 44100  2o     `Digital Audio (S/PDIF) (2- High'
  API 1 'Windows DirectSound' with 3 devices:
  |- 44100 +2o     `Primary Sound Driver'
  |- 44100  8o     `Speakers (2- High Definition Audio Device)'
  |- 44100  2o     `Digital Audio (S/PDIF) (2- High Definition Audio Device)'
  API 2 'ASIO' with 0 devices:
  API 3 'Windows WASAPI' with 2 devices:
  |- 44100 +2o     `Speakers (2- High Definition Audio Device)'
  |- 44100  2o     `Digital Audio (S/PDIF) (2- High Definition Audio Device)'
  API 4 'Windows WDM-KS' with 0 devices:
-------------------------

[Evan Balster]

Hmm, that's a bug in the portaudio driver layer.  It's angry about either the high number of output channels or (more likely) the lack of a microphone input on your system...  I'd be interested in your help with debugging that, as I don't own a system without a mike.

[InfiniteStateMachine]

sure no problem. I pmed you my email address.

[Ludophonic]

I needed an audio library for my current project and SDL_Mixer looked like it might become a little limiting so I decided to try out plaid.

I had to do a little work on it to get it going.

• Fixed the crash when no mic is present mentioned in the previous couple posts.
• Rebuilt PortAudio without debug print spam.
• Added libraries built with Visual Studio 2012 and 2013 to the VS2010 ones that are in the zip.
• Added project files for Visual Studio 2012 and 2013.
• Fix some small compile errors under VS2013.
• Wrote a simple SDL2 audio driver. (output only)

I've placed my modified version in GitHub if anyone is interested. I'll be updating it with Xcode project files and any needed OS X fixes within the next couple days. https://github.com/Ludophonic/plaidaudio

Thanks a lot for the library!

[Evan Balster]

At some point in the next month or two I should be getting a version 0.3 out.  (The code is there, it just needs documented and I'm super busy this month!)  I've made lots of changes and fixes, with the main one being an overhaul of the Driver and Scheduler handling -- it's now possible to select devices, run multiple audio streams at once and manually handle audio processes.  Though few end-users will have need for that, it came with lots of improvements to the underlying systems.  (and the mike bug is fixed, natch)

If it comes later rather than sooner, the update might include support for recording audio, more sophisticated filters, and possibly reverb.

[Klaim]

I was going to start using Plaid Audio 0.2 tomorrow, but I could work on something else first until you release 0.3.

[Ludophonic]

Can I load a wav file into an AudioClip directly (assuming i've written code to read it off disk, parse the header and such)?

Or is the preferred way to write a streaming codec and then stream the entire file into an AudioClip?

[Evan Balster]

Klaim -- It's unlikely the interface will change much between 0.2 and 0.3, excepting the interface from which driver layers need to inherit.  Which is to say compatibility with applications should be mostly preserved, but driver-layers written on 0.2 may need to be re-structured for 0.3.

Ludophonic -- writing a stream codec is the standard approach.  I definitely plan on supporting manual setup, eventually -- just haven't gotten round to making AudioClip feature-complete yet.

EDIT:  One major change that I think will be appreciated, BUT will require changes to client code:  I've done away with the wide-strings business.  I'm migrating my tech to UTF-8.

[Klaim]

Nice. Already using UTF-8 everywhere.

[Ludophonic]

Ludophonic -- writing a stream codec is the standard approach.  I definitely plan on supporting manual setup, eventually -- just haven't gotten round to making AudioClip feature-complete yet.

Thanks. Wrote a WAV stream codec and got this working. Time to integrate everything into the actual game now.

EDIT:  One major change that I think will be appreciated, BUT will require changes to client code:  I've done away with the wide-strings business.  I'm migrating my tech to UTF-8.

Yay! I'm also UTF-8 everywhere.

[Ludophonic]

I've added a WAV streamer and some small fixes to compile under Xcode to my git repo if anyone has need.