Fix OpenAL context management

[binary1248]

I Introduced AlResource to manage contexts the same way it is done for GlResources. The Listener properties are now part of the context itself and thus moved to the rest of the AudioDevice code so they can be delay applied if the user chooses to set them before a resource is constructed and reapplied if there is temporarily no context. sf::Listener just proxies everything to the AudioDevice which stores the values itself. This way no changes to the public API have to be made.

Because the AL context lifetime is tied to the lifetime of the resources that require it, unless the user decides to have global audio resources, the context should be destroyed before main() returns. This is a fix for #30.

[LaurentGomila]

A lot of code in AudioDevice is duplicated. Is there no way to avoid this?

[binary1248]

Unless you want to drop exception safety... no 😄

[LaurentGomila]

What about this:

void commonStuff()
{
    ...
}

void AudioDevice::stuff()
{
    if (!audioDevice)
    {
        AudioDevice device;
        commonStuff();
    }
    else
    {
        commonStuff();
    }
}

But I don't like to split functions this way, so maybe an auto/whatever ptr would be better.

[binary1248]

Replaced the duplicated code with auto_ptr<AudioDevice> in latest version.

[MarioLiebisch]

Do we really need std::auto_ptr? Not sure about compatibility with older compilers and as far as I know it's deprecated with C++11 anyway.

[Bromeon]

The advantage of std::auto_ptr is that it can be replaced with std::unique_ptr when SFML starts to use C++11. And of course, RAII is generally preferable to raw new and delete.

[MarioLiebisch]

I'm aware of that, I'm just not sure it's available everywhere.

[Bromeon]

I'm aware of that, I'm just not sure it's available everywhere.

std::auto_ptr has been in the C++ standard since 1998. Compilers that compile C++98 must support it.

[MarioLiebisch]

Okay, that sounds reasonable. :)

[TankOs]

No negative review, so I guess this can be merged?

[LaurentGomila]

Looks good, yes, but I wouldn't include it in SFML 2.2. Such a modification should be tested as much as possible by users to make sure it doesn't break anything.

[TankOs]

Sounds reasonable. :)

[TankOs]

Merged in develop branch, bugfix branch can be deleted.

[TankOs]

Will keep this open until milestone is hit...

[eXpl0it3r]

Looks good, yes, but I wouldn't include it in SFML 2.2. Such a modification should be tested as much as possible by users to make sure it doesn't break anything.

Given the amount of branches pilling up next to the list of issues and seeing the age of the issue, I don't think it's a good idea to just postpone the merge. If you're lucky one or two more people will actually bother compiling this branch and run it other than that, it most likely will never get tested well enough.

By changing the way we develop things, after SFML 2.2 we're no longer stuck on the 2.x branch, but can deploy hotfixes for critical issues. And with a hopefully reduced release cycle, we'll be able to push out enhancements way quicker. Thus the best way to actually test this, is to put it into the wild (or maybe something like an unstable branch).

[LaurentGomila]

What's wrong with merging it after 2.2 is released, so that it can be tested as long as we work on 2.3? Still much better than releasing a broken version and having to release a patch version in a hurry, in my opinion.

[Bromeon]

I would also wait, it's better if SFML 2.2. contains less features, but is more stable. The number of branches piling up alone isn't reason enough to merge ;)

Furthermore, this context-related functionality is very subtle when it comes to errors depending on the used variable scope, different drivers and other factors. It will really need some testing, preferably an automated one. Maybe this can be a case for the unit tests once we start integrating them.

[binary1248]

Is this still blocked by 2.2? I don't mind, but considering this doesn't add or remove features and fixes one of the longest lived bugs, it might be worth considering for 2.2 as well.

[LaurentGomila]

It needs testing. And it won't be tested until it is merged into master, which is always postponed because we think SFML 2.2 is about to be released :D

[binary1248]

So.... what now? 😛

I think we can agree that 2.2 won't be done as soon as we anticipated 😉.

[LaurentGomila]

That's right, but I don't think we're in a hurry for merging this modification, are we?

[binary1248]

Well.... if there really is nothing else left to merge in a month and 2.2 is still waiting for certain things to be done... 😁.

[TankOs]

Positive test from me side. However I'd like to have a test that I can run that covers all changes. The sound and sound_capture examples are not enough.

[eXpl0it3r]

Needs a rebase and further testing.

[binary1248]

Rebased.

[eXpl0it3r]

After some people give the green light, I'll be merging this branch.

[LaurentGomila]

Minor suggestion: add a comment which explains that device doesn't need to be used in the function because creating an AudioDevice will automatically set the audioDevice global variable. I spent 5 minutes analyzing the code and was about to report a mistake.

[LaurentGomila]

Apart from the two minor comments that I posted, it looks good to me.

[binary1248]

Issues fixed in latest commit.

[LaurentGomila]

👍 for me

[mantognini]

Tested very quickly, works like a charm.

[binary1248]

Updated commit with .reset().

[eXpl0it3r]

This PR has been added to my merge list, meaning it will be merged soon, unless someone raises any concerns.