Page MenuHome

Crash when starting playback while using JACK audio with A/V sync
Closed, ResolvedPublic

Description

To reproduce:

  1. Run Blender
  2. Change Audio backend to "Jack" (should be "JACK" - all letters uppercase, because it's an acronym, but nevermind).
  3. Enable Audio/Video sync using the Sync Mode combobox on the Timeline header.
  4. Run Ardour (or another program that uses JACK transport)
  5. Move the playhead in BLender to make sure that the playhead in Ardour follows along.
  6. Press play (Spacebar) in Ardour or press play (Alt+A) in Blender
  7. Watch Blender segfault.

What's interesting: I can move the playhead within Ardour, and it's synced to Blender - no crashes. It only crashes if I start (or stop) playback from Ardour when Blneder is synced to JACK transport.

When I disable "A/V Sync" - Blender never crashed when starting animation playback, even though JACK was still used as an audio backend.

I was testing this also with 2.76b and the issue is much more random there. Sometimes I can start playback with another JACK-transport enabled programs and Blender follows without crash for a few times in row, and suddenly it will crash.

Here's a backtrace I got from 2.78:

# Blender 2.78 (sub 0), Commit date: 2016-09-26 12:42, Hash 4bb1e22

# backtrace
/unfa/Applications/Blender/blender(BLI_system_backtrace+0x1d) [0x1b6269d]
/unfa/Applications/Blender/blender() [0x11bc81e]
/lib/x86_64-linux-gnu/libc.so.6(+0x354a0) [0x7fb37079f4a0]
/unfa/Applications/Blender/blender(ED_screen_animation_timer+0x1ad) [0x149e5bd]
/unfa/Applications/Blender/blender(ED_screen_animation_play+0xc2) [0x14a56c2]
/unfa/Applications/Blender/blender(wm_event_do_handlers+0x853) [0x11c6853]
/unfa/Applications/Blender/blender(WM_main+0x18) [0x11bd428]
/unfa/Applications/Blender/blender(main+0x3b3) [0x11620c3]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7fb37078a830]
/unfa/Applications/Blender/blender() [0x11b96c9]

And the same problem with 2.76 too, sometimes also happens when I start playback withing Blender (Alt+A):

# Blender 2.76 (sub 0), Commit date: 1970-01-01 00:00, Hash unknown
bpy.data.grease_pencil["GPencil"].(null) = 0  # Property
bpy.data.grease_pencil["GPencil"].(null) = 1  # Property
bpy.ops.transform.transform(mode='TIME_TRANSLATE', value=(15.0921, 0, 0, 0), axis=(0, 0, 0), constraint_axis=(False, False, False), constraint_orientation='GLOBAL', mirror=False, proportional='DISABLED', proportional_edit_falloff='SMOOTH', proportional_size=1)  # Operator
bpy.data.grease_pencil["GPencil"].(null) = 0  # Property
bpy.ops.action.duplicate_move(ACTION_OT_duplicate={}, TRANSFORM_OT_transform={"mode":'<UNKNOWN ENUM>', "value":(43.1202, 0, 0, 0), "axis":(0, 0, 0), "constraint_axis":(False, False, False), "constraint_orientation":'GLOBAL', "mirror":False, "proportional":'DISABLED', "proportional_edit_falloff":'SMOOTH', "proportional_size":1, "snap":False, "snap_target":'CLOSEST', "snap_point":(0, 0, 0), "snap_align":False, "snap_normal":(0, 0, 0), "gpencil_strokes":False, "release_confirm":False})  # Operator
bpy.ops.transform.transform(mode='TIME_TRANSLATE', value=(10.4207, 0, 0, 0), axis=(0, 0, 0), constraint_axis=(False, False, False), constraint_orientation='GLOBAL', mirror=False, proportional='DISABLED', proportional_edit_falloff='SMOOTH', proportional_size=1)  # Operator
bpy.ops.transform.transform(mode='TIME_TRANSLATE', value=(6.46799, 0, 0, 0), axis=(0, 0, 0), constraint_axis=(False, False, False), constraint_orientation='GLOBAL', mirror=False, proportional='DISABLED', proportional_edit_falloff='SMOOTH', proportional_size=1)  # Operator
bpy.ops.transform.transform(mode='TIME_TRANSLATE', value=(2.15601, 0, 0, 0), axis=(0, 0, 0), constraint_axis=(False, False, False), constraint_orientation='GLOBAL', mirror=False, proportional='DISABLED', proportional_edit_falloff='SMOOTH', proportional_size=1)  # Operator
bpy.ops.action.duplicate_move(ACTION_OT_duplicate={}, TRANSFORM_OT_transform={"mode":'<UNKNOWN ENUM>', "value":(15.8107, 0, 0, 0), "axis":(0, 0, 0), "constraint_axis":(False, False, False), "constraint_orientation":'GLOBAL', "mirror":False, "proportional":'DISABLED', "proportional_edit_falloff":'SMOOTH', "proportional_size":1, "snap":False, "snap_target":'CLOSEST', "snap_point":(0, 0, 0), "snap_align":False, "snap_normal":(0, 0, 0), "gpencil_strokes":False, "release_confirm":False})  # Operator
bpy.ops.action.duplicate_move(ACTION_OT_duplicate={}, TRANSFORM_OT_transform={"mode":'<UNKNOWN ENUM>', "value":(6.1087, 0, 0, 0), "axis":(0, 0, 0), "constraint_axis":(False, False, False), "constraint_orientation":'GLOBAL', "mirror":False, "proportional":'DISABLED', "proportional_edit_falloff":'SMOOTH', "proportional_size":1, "snap":False, "snap_target":'CLOSEST', "snap_point":(0, 0, 0), "snap_align":False, "snap_normal":(0, 0, 0), "gpencil_strokes":False, "release_confirm":False})  # Operator
bpy.ops.transform.transform(mode='TIME_TRANSLATE', value=(0.718689, 0, 0, 0), axis=(0, 0, 0), constraint_axis=(False, False, False), constraint_orientation='GLOBAL', mirror=False, proportional='DISABLED', proportional_edit_falloff='SMOOTH', proportional_size=1)  # Operator

# backtrace
blender(BLI_system_backtrace+0x30) [0x1361b10]
blender() [0x97a98e]
/lib/x86_64-linux-gnu/libc.so.6(+0x354a0) [0x7fe25ba6d4a0]
blender() [0x1148e84]
blender(_ZN14AUD_JackDevice17updateRingBuffersEv+0xef) [0x172388f]
blender(_ZN14AUD_JackDevice15runMixingThreadEPv+0x9) [0x1723a99]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x76fa) [0x7fe25fe346fa]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7fe25bb3eb5d]

I'm trying to workaround this by performing all playhead moves inside Blender - I can arm recording in Ardour and start/stop the recording from Blender. Not convenient, but seems to prevent Blender from crashing for now.

EDIT: This isn't a real workaround, as Blender still crashes when I start playback from it. What's better is that it dones't crash every single time - roughly only once every 5 times.

Here's a backtrace I got when I started playback from within Blender.
I pressed Alt+A, blender crashed immediately, but Ardour started playback fine:

# Blender 2.78 (sub 0), Commit date: 2016-09-26 12:42, Hash 4bb1e22
bpy.data.window_managers["WinMan"].(null) = True  # Property

# backtrace
/unfa/Applications/Blender/blender(BLI_system_backtrace+0x1d) [0x1b6269d]
/unfa/Applications/Blender/blender() [0x11bc81e]
/lib/x86_64-linux-gnu/libc.so.6(+0x354a0) [0x7f75d7d654a0]
/unfa/Applications/Blender/blender() [0x1966554]
/unfa/Applications/Blender/blender(_ZN14AUD_JackDevice17updateRingBuffersEv+0xc9) [0x1fc2af9]
/unfa/Applications/Blender/blender(_ZN14AUD_JackDevice15runMixingThreadEPv+0x9) [0x1fc2cd9]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x76fa) [0x7f75d935f6fa]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f75d7e36b5d]

Event Timeline

Tobiasz Karoń (unfa) updated the task description. (Show Details)
Tobiasz Karoń (unfa) updated the task description. (Show Details)
Tobiasz Karoń (unfa) renamed this task from Crash when another program starts playback while using JACK audio with A/V sync to Crash when starting playback while using JACK audio with A/V sync.Oct 14 2016, 1:31 PM
Tobiasz Karoń (unfa) updated the task description. (Show Details)
Tobiasz Karoń (unfa) updated the task description. (Show Details)

@Tobiasz Karoń (unfa): can you try with this fix if it works for you? For me it works fine now, but maybe I didn't catch all cases where it crashes. If you don't build blender yourself, you can try a version from a build bot that's new and includes that revision.

@Joerg Mueller (nexyon): I'll happily try it, I don't build Blender myslelf so I'll resort to the Build Bot. Thank you!

Ok On my side the automatic build from Sat Oct 22 04:03:33 2016 does not use JACK transport at all.

I see no communication between Blender and Ardour. I can't get them to sync the playback.

Well, how do you expect a change made at 3 PM to be included in a build from 4 AM? You'll have to wait for a new build!

Sorry! I didn't see when you've commited your patch!

I tested today with a recent Blender build:

Linux 64 bit 	Official 	blender-2.78-216a3a3-linux-glibc211-x86_64.tar.bz2 	116M 	Fri Oct 28 02:15:00 2016

And the JACK transport is even more broken than it was before. It doesn't crash, but when using JACK with A/V Sync, Blender gets stuck on 2 frames alternating between them every time I press play (in Blender or in a remote JACK application, starting JACK transport).

I can scrub the timeline in Ardour and Blender responds.

Sometimes when I leave it "playing" and Blender is stuck on the two frames, after some time it breaks free and starts normal playback somehow.
But that's unpredictable and rare, so it's not usable.

I'm reopening this issue.

Tobiasz Karoń (unfa) reopened this task as Open.Oct 28 2016, 10:56 AM
Tobiasz Karoń (unfa) closed this task as Resolved.EditedOct 28 2016, 11:07 AM

False alarm.

I testes in another version of Blender and the stutter also happens, so it's not introduced by any recent commit.

Looks like my JACK server got hiccups, after restart it all works as expected. I was unable to reproduce a crash with JACK transport playback so far.

Thank you!

If the stutter issue happens again, I'll file it as another problem.