Page MenuHome

Crash/freeze when using Audio Scrubbing for a while (in VSE and in general)
Closed, ResolvedPublic

Description

When making (extensive) use of Audio Scrubbing first the sound goes away and if Blender is not closed soon after that it will crash/freeze and may even take down the whole system (reset button needed).

This is with Blender 2.58a under Ubuntu 10.10. (The bug is not new, I am only reporting it now since similar bugs were previously fixed and I was hoping the issue would be solved.)

Workaround: only use Audio Scrubbing for a short moment and deactivate after that.

See the attached .blend, simply move the play head (fast) over the sound strip continuously for about 1-2 Minutes to hear the audio going away all of a sudden. This is similar to using the Audio Scrubbing feature in a situation when e.g. working on a video clip and first trying to find all the right sound cues/setting your Markers - the bug won't show if you only use Audio Scrubbing once in a while...!

Details

Type
Bug

Event Timeline

Tested on an ubuntu 11.04 trunk and the sound went away when using OpenAL, could not crash/freeze blender though. After the sound faded I could still change to SDL from the user preferences and use it the same way, but with it I couldn't duplicate this.

Valentin, have you tried this using SDL? Also, you should probably attach a version where the sound_test.wav is packed within the file (unless it's huge), I tested with some random sound.

I meant to say ubuntu 11.04 with blender revision 38452

I attached a patch suggestion; the m_thread is created as a joinable thread, yet it's only joined in the destructor. Solution: see if m_thread has been running and do a pthread_join in case it has. This is a one file (cpp) change atm, the has_been_running should probably be a member but would like to see if it works for other people before adding things to headers.

The diff also contains a small change to move m_playing = false; to be "inside" lock and unlock in updateStreams(), just to be on the safe side.

Joerg: easy one for you, it has a fix even!

Attaching the cleaned up patch (27913.diff); m_dothreadjoin is basicly set to true after the thread is run for the first time and pthread_join is called in start() and the destructor accordingly. The change to have m_playing = false; to be between lock/unlock is included in this one too.

Juha, thanks for looking into this. I did not pack the sound in the file since for me the issue is there with any sound I've used so far (that .wav from the .blend is just some quick Audacity generated test). However if you still need it, I'd post it of course...

I am not a developer and therefore have not tried SDL, if I can test something for you let me know, though I'd need clear instructions (like what SDL is/how it works).

Just an additional note: the issue might seem minor, which it is as long as Audio Scrubbing is off (it is of course by default). Yet once it's on users might experience "random" crashes and not easily find out what the real problem is. Basically working/editing with sound while using Audio Scrubbing means you have to save often and open/close Blender every couple of minutes or turn Audio Scrubbing on and off every time you use it...

Thanks!

Valentin, thanks for volunteering! SDL (Simple DirectMedia Layer) is a library for hardware access, basic sound among other things. If your blender was built with it then User Preferences -> System tab -> and there you should have Sound: None, SDL, OpenAL. Just select SDL from there and you're set.

The fix I'm proposing assumes the issue is with blenders OpenAL code so if you get sound going away or crashes with SDL too... well, it's back to the drawing board. I am not 100% if these two symptoms are directly related so if you have either issue or both with SDL it would be good to know.

Juha, it looks like you've found it: when I switch to SDL I can scrub over a test clip for two minutes and still have sound in Blender. Same test clip with the default setting (OpenAL) and Blender looses sound within (less than) a minute....

Looks good and I now also know how-to use Audio Scrubbing the way I need it until a fix is officially there!

Hi!

Sorry for the late reply, didn't have internet for the last couple of days. So I did a lot of scrubbing but couldn't reproduce the problem. Anyway, I can understand why this is happening. Thanks for the patch, but from my understanding it should be enough to move the m_playing = false; in updateStreams before the unlock, could you try if this simple change is sufficient?

Regards

I've committed the fix we talked about in IRC in revision 38631. Fixed & Closed.

Joerg Mueller (nexyon) closed this task as Resolved.Jul 23 2011, 6:12 PM

Tested trunk (5 minutes of continuous scrubbing:) and it works. Thank you!