5

I could not find detailed explanation about this function. What I want to know now is that:

Will this function block current thread? Or it just tells the device to start playing audio asynchronously any returns at once?

Andrew Chang
  • 1,289
  • 1
  • 18
  • 38

1 Answers1

2

Yes, the code which wraps your call to alSourcePlay is blocking so wants to be in its own thread. OpenAL has its own event loop to buffer up and render sound into the audio device(s).

Typically you want a separate thread to make available your source media (thread 1) and another thread for your OpenAL logic (thread 2). This is in addition to your UI thread (thread 3) if any.

Scott Stensland
  • 26,870
  • 12
  • 93
  • 104
  • For example, I should do this: {background thread} --write PCM data--> [shared buffer] --read--> {main thread}. The background thread fetches data while the main thread play (call `alSourcePlay`) them? – Andrew Chang Apr 29 '14 at 00:35
  • 1
    If the end user interacts with your software, as opposed to a stand alone process with no user interface, the UI code wants its own thread which typically is the main thread. An additional thread is needed to deal with media fetching/decoding and I/O. A third thread is devoted to the logic surrounding OpenAL code. However, if you are just playing about and want to kick the tires of OpenAL and do not mind an unresponsive process during playback then go ahead and do it all in a single thread, OpenAL does not mind but it will hang the application throughout media playback. – Scott Stensland Apr 29 '14 at 19:32