Arx Libertatis Bug Tracker
Please log in to bookmark issues
CLOSED  Bug report #4  -  Pthread audio
Posted Feb 06, 2011 - updated Mar 07, 2012   Shortlink:
icon_info.png This issue has been closed with status "Fixed" and resolution "RESOLVED".
Issue details
  • Type of issue
    Bug report
  • Status
  • Assigned to
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
  • Posted by
  • Owned by
    Not owned by anyone
  • Estimated time
    Not estimated
  • Time spent
    369294 hours
  • Category
    Not determined
  • Resolution
  • Priority
    Not determined
  • Reproducability
    Not determined
  • Severity
  • Targetted for
    icon_milestones.png Not determined
  • OS
    icon_customdatatype.png Not determined
  • Architecture
    icon_customdatatype.png Not determined
  • Fixed in
    icon_customdatatype.png Not determined
Issue description
This branch removes the Windows-specific threading calls from the audio subsystem and puts POSIX threads calls in their place.

(There are a lot of commits in there, because I initially forked the wrong repo, and made some changes to that. Almost all are deleted, though, and the amount of code that actually changes is very small.)
Steps to reproduce this issue
Nothing entered.

Comment posted by
Feb 07, 16:31
Thank you for your patch. I have moved the hard coded define to cmake, and also changed the linking only to be done on gcc. Sadly i have no working audio on your branch, so i didn't merge it to master yet. But pthread-audio is now a branch on my repository. We are planning to exchange the audio subsystem with a high level library, like sfml-audio, so we don't have to do platform checking at all places. What do you think of that? So your changes are an improvement, to do it the POSIX way, but may only be temporary. I would have merged it with master if my audio was working properly. Any idea why it does not work? Why is the WaitForSingleObject a define? I understand you have implemented the windows api function yourself. But in the future we want to get rid of the winapi calls.