Ticket #931 (closed defect: duplicate)
[PATCH] Fix OpenAL issues on OS X
| Reported by: | jan | Owned by: | stwf |
|---|---|---|---|
| Priority: | Must Have | Milestone: | |
| Component: | Core engine | Keywords: | patch |
| Cc: | Kimball |
Description (last modified by kenny) (diff)
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. (kenny)
Attachments
Change History
comment:1 Changed 22 months ago by jan
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 Changed 22 months ago by k776
- Keywords patch, review added
- Priority changed from Should Have to Must Have
- Summary changed from Fix OpenAL issues on OS X to [PATCH] Fix OpenAL issues on OS X
comment:4 Changed 22 months ago by k776
- Priority changed from Must Have to Should Have
- Milestone changed from Alpha 7 to Alpha 8
comment:5 Changed 19 months ago by kenny
- Cc KennyLong removed
- Owner changed from Sound Department to kenny
comment:6 Changed 19 months ago by kenny
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:10 Changed 18 months ago by k776
- Priority changed from Should Have to Must Have
- Milestone changed from Alpha 8 to Alpha 9
Pushing to Alpha 9 and raising priority. Kenny, what's the progress on this?
comment:11 Changed 18 months ago by Juicyfruit
Changing the OpenAL library to OpenAL-soft post compile also fixes the issues for me.
This is trivial to do and requires no code changes whatsoever.
I used git-current from: http://repo.or.cz/w/openal-soft.git
comment:12 Changed 16 months ago by historic_bruno
- Owner kenny deleted
- Status changed from assigned to new
comment:15 Changed 15 months ago by historic_bruno
- Component changed from Music & Sound FX to Core engine
comment:17 Changed 13 months ago by raymond
Please increase the priority of fixing this issue. This issue is permanently moved to next alpha version :(
comment:18 Changed 13 months ago by k776
@raymond It kept getting moved because we wanted to fix it, but had no one to do so. We have a person working on it now (stwf), so it should be fixed in Alpha 11, or Alpha 12 at the latest.
comment:19 Changed 13 months ago by k776
- Status changed from assigned to closed
- Resolution set to duplicate
- Milestone Alpha 11 deleted
Merged with #1223
comment:20 Changed 10 months ago by ben
In 12428:
