Ok, here are my thaughts of different possiblities:

• Bug in OpenAL and SDL because blender is not playing any sound, just having a context shouldn't prevent windows from sleeping.
• Bug in Windows or the audio driver for not recognizing when there is actually no audio being played.
• Feature request for Blender to close and open the audio device when unused.

Just having a context in OpenGL doesn't prevent it from sleeping either, right? So it should be the same with OpenAL...

Regarding the feature request I don't think that's a solution, because users don't play audio with blender constantly. They play the animation/scrub and then stop again having no audio playing and start again. Closing and opening the audio device every time here doesn't make sense and most likely has a horrible performance. Shutting it down after a while of not being used shouldn't be a problem application programers should have to worry about, so that's an argument for the first two possibilities.

As a workaround for you I would suggest that you set the audio backend to None if you don't need audio in Blender, or just close it or manually hibernate the computer.

Any thoughts about this by anyone else?

I agree that shutting the context down after inactivity isn't amazing, but that doesn't seem like much of an argument for not doing it. If it's difficult then could context creation be delayed until required instead?

This behaviour can be disabled system-wide with the command powercfg -REQUESTSOVERRIDE DRIVER <driver name> but then you'll find the system entering standby while idly playing music (unless your media player makes its own powercfg request).

Here's a patch that makes context creation and destruction dynamic.

Jack isn't covered as I can't get it working, but since it isn't included in official Windows builds that's not a huge problem IMO.

Hi!

I'm sorry, I cannot accept this patch for several reasons:

First and most important: I don't think this is the right place to solve this issue code design wise. Better would be do have some kind of adapter device that can shutdown/recreate the devices. Obviously that would give problems with paused sounds, but the audio code in Blender can handle this already (it checks for invalidated handles on playback). The big advantage of this is, that it would work with any backend and you can easily add an option to the configuration to en-/disable this feature.

Second there are quite some problems in this code regarding multithreading and error handling that I can see right away without even applying the patch, like for example locking without unlocking if there's an exception thrown, etc.

Third it is not following the code style rules of blender, most of the patch consists of invalid CS changes, see http://wiki.blender.org/index.php/Dev:Doc/Code_Style

Regards

Thanks for getting back!

An adapter which creates and destroys whole device objects is an elegant idea but does present a few problems. Specifically:

• OpenAL can have EAX effects active, such as reverb, which means that we can't be sure when sound output will actually end. In the patch above I don't shut down OpenAL until 1000ms have passed since Blender thinks audio output ceased, but I suspect a better solution will be needed...
• Constructing Jack took an appreciable amount of time on my system, probably due to it searching for the server. That shouldn't happen every time the user starts or stops playback.

IMO creation/destruction being implemented in the AUD_SoftwareDevice base class is a sensible middle ground. Fancy devices like OpenAL and Jack need finer control over this sort of thing.

Thanks for spotting the exception handing issue, I've fixed that locally now. You'll have to point out where the threading issues are I'm afraid as I'm not familiar with Blender's general threading systems.

The code style changes are done by Visual Studio whenever I paste or type closing braces. Most are actually making changes that the wiki is asking for (space between statement and brace), but I'm really not bothered either way. I'll wait until the rest of the patch is good before removing them otherwise I'll be fighting with the IDE a lot!

The adapter is exactly the perfect solution for the two problems you mentioned: It should definitely not shutdown immediately after all sounds are stopped, but have a delay that is configurable in the user settings (between immediately and never), that solves the EAX problems as much as the Jack construction problems perfectly.

Having it in AUD_SoftwareDevice as you said adds it to Jack too, as the Jack and SDL backends are both constructed on this. Also the AUD_SoftwareDevice is used for non-realtime playback devices such as for audio rendering. Having a time-dependend feature in there is not a good design idea.

Also audaspace should get released as an external library soon(tm) (if I find time for it... :-/) and I'm pretty sure not every user will want this feature to be in the device code itself.

Regarding threading: Audaspace is independend of blender, so it manages it's own threading. What I originally meant with the threading problems is the not-unlocking during exceptions. I'd have to take a closer look at the patch for spot if there are other threading/performance problems.

And last but not least: you should be able to configure your IDE to not do any unwanted CS changes. The rule I was refering to in the link is the very top most (which is one of the only two important ones): "When making changes, conform to the style and conventions of the surrounding code."

Here's what I've got so far. It uses some C++11 features, but I read on the mailing list that Audaspace is going to require that soon anyway. :)

The bad new is that SDL will crash after a bit of scrubbing due to its handles trying to access the destroyed SDL device. The obvious fix is to invalidate the handles so that they have to be regenerated via AUD_IDevice::play(), but I'm not sure how to do that. My attempts (patch line 120) just cause ugly memory allocation crashes deep in the CRT.

The good news is that my worries about OpenAL are unfounded: EAX effects continue even after the context has been destroyed. I don't think we'll have to worry about anything in that area.

I've not looked into Jack yet.

Don't worry @Sergey Sharybin (sergey), I was assigned already and I'm still subscribed. The reason I unassigned myself is to give other people a chance to implement this.

@Tom Edwards (artfunkel): thanks for your second patch, this looks better already. Right now the library is going through some major refactors and I already have some ideas on how to implement this feature in a similar, but still different way. I'll look into it, when the time is there to add new features again. For now I guess you can use your patch and other people don't seem to have the same problem so much. ;-)

T38702 is a duplicate of this more or less, just on Mac. Work on integrating the github version of the library into blender was finished today for Linux. As soon as the library builds on Windows and Mac, we'll look into a good way to completely switch to it and then we can add new features, like a device code that automatically shuts down if nothing is played back for a while.

Even without testing I'm quite sure that this still happens, as nobody implemented a feature to fix this.

Wrt. the sound artifacts: yes, those artifacts exist and can probably produced with any software, as the problem can't really be fixed. The pops/cracks are the same as stuttering when you have low FPS and the hiss is probably introduced due to clipping so what would be necessary is to lower the volume on those overlapping strips.