Opened 13 years ago

Last modified 12 years ago

#931 closed defect

[PATCH] Fix OpenAL issues on OS X — at Version 7

Reported by: Jan Wassenberg Owned by: Kenny Long
Priority: Must Have Milestone:
Component: Core engine Keywords: patch
Cc: Kimball Patch:

Description (last modified by Kenny Long)

OS X CoreAudio has some trouble with our reuse of sources (see http://www.wildfiregames.com/forum/index.php?showtopic=15066). There are various bandaids such as FIFO reuse (thus giving CoreAudio more time to finish what it's doing before we reset the source properties). However, one proper fix might be to just generate/delete sources anew.

This used to be super expensive on hardware implementations, but OpenALsoft should manage much faster. I have implemented this approach (see attached patch) and run a quick test.

With the old suballocator, running -autostart="We Are Legion", sending the front middle guy forwards and waiting for the dust to clear, I see tc_OpenAL_source: 3790.03 kc (5203x) (about 0.2 us per alloc). The new patched version gets tc_OpenAL_source: 239.762 Mc (5411x). Apparently the battle went slightly differently, there were also more casualties, but the per-alloc cost is indeed higher (14 us). Still nothing to worry about; I think this approach is fine on software implementations of OpenAL.

I'd appreciate people testing this on OS X, which requires removing the little kill-switch in hwdetect.js.

Questions:

1) does this fix the issues?

2) is the per-alloc overhead [converting the above number to seconds by dividing by the CPU clock and normalizing according to the number of calls (in parentheses)] similar?

Jan - this didn't work. See my notes below.

Change History (9)

by Jan Wassenberg, 13 years ago

comment:1 by Jan Wassenberg, 13 years ago

Here is the original analysis by mtkaz concerning these issues: http://www.wildfiregames.com/forum/index.php?showtopic=14895&st=0 Thanks for that, we are hopefully close to fixing them!

As mentioned in the meeting, the loop issue should be fixable by returning 0 from vsrc_deque_finished_bufs if vs->loop is true.

comment:2 by Kieran P, 13 years ago

Keywords: patch review added
Priority: Should HaveMust Have
Summary: Fix OpenAL issues on OS X[PATCH] Fix OpenAL issues on OS X

comment:3 by historic_bruno, 13 years ago

Keywords: review removed

comment:4 by Kieran P, 13 years ago

Milestone: Alpha 7Alpha 8
Priority: Must HaveShould Have

comment:5 by Kenny Long, 13 years ago

Cc: KennyLong removed
Owner: changed from Sound Department to Kenny Long

comment:6 by Kenny Long, 13 years ago

After a lot of testing and reading the spec I discovered that the source attribute for looping is not meant to be mixed with the streaming buffers APIs in OpenAL. For some reason this works in Win and Linux even though the spec says they are not to be mixed. This is why the OS X version tries to hold onto all the buffers when the source attribute for looping is set. If I disable looping the standard version of OpenAL on O SX works (partially - it doesn't repeat). So I think I can just change the sound update code to handle the looping and that will fix that problem.

Anyway, I think we can keep the sub allocation for sources and buffers. There does seem to be another problem with freeing the buffers on O SX that I am still looking into.

comment:7 by Kenny Long, 13 years ago

Description: modified (diff)
Note: See TracTickets for help on using tickets.