Blender crashes using Jack with AV Sync enabled (repeatable) #72632
Operating system: Linux-4.18.0-25-generic-x86_64-with-debian-buster-sid 64 Bits
Graphics card: GeForce GTX 1060 6GB/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 390.116
Broken: version: 2.81 (sub 16), branch: master, commit date: 2019-12-04 11:32, hash:
Short description of error
Blender crashes while scrubbing when AV Sync is enabled and system is using JACK audio
Exact steps for others to reproduce the error
- open blender 2.81a with fresh config dir
- enter prefs -> System and choose JACK as audio device
- go to VSE, add audio clip of whatever length to at least fill the default frames (I used a standard stereo 16bit PCM .wav in this case)
- in Timeline, enable AV Sync option
- play the animation, and scrub around with the mouse on the timeline
It takes a while of constant scrubbing for me -- sometimes 30 seconds or even 1-2 minutes, but I can reliably make Blender crash this way. (Sometimes I stop and jump around in the timeline, left/right-arrow a little, etc... not sure if any of that is necessary.) Two crash.txt's are attached.
The issue is caused by race condition between JACK callback and dependency graph update.
One of the ideas to get it solved is to make JACK callback to act more like a tag (rahtehr than an actual action) which will allow handling it as soon as possible but not from the place where it can't be happening in a thread-safe manner.
Changed status from 'Needs Triage' to: 'Confirmed'
Can confirm in a buildbot build.
(havent built with JACK myself yet, but...confirming for now)
The crash happens as follows, when you use JACK and AV-sync, JACK transport is enabled meaning that JACK will call the
sound_sync_callback, which down the road
sound_sync_callback -> sound_jack_sync_callback -> BKE_sound_jack_scene_update -> BKE_sound_play_scene -> sound_start_play_scene -> AUD_Device_play
I figured that this is due to
SceneBackup setting it so in Blender's main thread, but that's as far as I can get since I don't know what this is for. While there is a chance that sound is playing back,
sound_scene should only be changed when the audio device is locked (
AUD_Device_lock(sound_device); ...; AUD_Device_unlock(sound_device);), however, locking the device should be as short as possible it will cause skips, clicks, other nasty sounds, hangs, etc...
Having a callback happening from the middle of dependency graph update will never be reliable.
The proper behavior would be to do some sort of tag from the
sound_jack_sync_callback which will indicate that the current frame and audio is to be updated once the event loop allows this.
Unassigning myself, it doesn't fir into my agenda. Can help with understanding the design, but can't be the one who fixes every single area.
This issue was referenced by
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?