Well simply skipping my audio update task seems to prevent it from deadlocking, or at least reduces the chance of deadlock by so much that I wasn’t able to make it happen. I should have some sample code soon.
I managed to separate out the audio portion of my code but it is not locking, probably because whatever other thing wanted the same data is now gone. It is for sure the audio system, setting the library to null there were no problems at all whereas otherwise it would deadlock in a few seconds.
Hmm, I don’t suppose you had things in different threads that were might have been starting the same sound object at once? How about starting different sound objects, but from different threads? Or loading sound objects? Or setting 3-D positional sound?
How many different threads do you have accessing sound at all?
David
I don’t have any custom threads, so it would just be the App/Cull/Draw pipeline and FMOD’s own thread that it creates. All of my audio stuff is happening in the main thread.
Actually I realized that the game does not seem to deadlock until I start doing stuff with an audiomanager other than the default one. Could it be that holding onto a reference to the audiomanager is a problem?
I can have another go at dismantling my code bit by bit again if that helps, it will just take a while.
Hmm, the only thing FMod does in its child threads (that relates to Panda) is to make callbacks into the vfs to read file data, and that should be thread-safe. Hmm. Does it crash if you:
(1) Try forcing all sound files to load fully in RAM by setting “fmod-audio-preload-threshold -1”?
(2) Switch to OpenAL?
(3) Use a single-threaded rendering model (by disabling graphics-threading-model)?
How about if you set “notify-level-audio debug” to get more debugging information? This should tell you when it is streaming data from sound files, which might give more insight into what is going on just before a crash.
I can’t think of any reason that having multiple AudioManagers could cause a problem, but I certainly can’t rule it out.
David
“fmod-audio-preload-threshold -1” is already set, as I had performance problems previously with streaming too many sounds.
I don’t have OpenAL in my current build but I will give it a try when I get a chance to do a new build. I remember having other issues with OpenAL previously in any configuration so it might fail for a different reason.
Using both a non-threaded build and single-threaded work just fine.
The last printout before deadlock seems to always be
:audio(debug): FmodAudioManager::audio_3d_set_listener_attributes()
That’s pretty damning, isn’t it? I bet the problem is somewhere in FmodAudioManager::audio_3d_set_listener_attributes(). 
Looking at that function now, it is only calling a method on the global FMod _system object, but that could be trouble if it gets called from separate threads, or even if it is only called from the main thread but there is something else FMod-related going on in another thread simultaneously.
I think all of these calls into the global _system object need to be protected with a mutex inside the p3fmod layer. I’ll try to make this change in the next few days, and we can see if it helps your crash.
David
Yeah I think the audio_3d_set_listener_attributes is a bit deceptive because it seems there are a lot of functions that don’t do a debug printout.
If I remove all my python calls to audio3dSetListenerAttributes there is still deadlock.
I’m actually going through right now and slowly removing any audio calls from my code to try and find out exactly what the cause is.
It didn’t take as long as I’d thought; I’ve just committed the changes that ought to protect all of the FMod stuff against multithreaded access. Give it a try and let me know if it does any better now.
David
Sorry to say it did not resolve the deadlock, I will continue to try to trim down my code until I have a smaller sample.
Also there was a build error introduced in regard to the recent pfm changes. Line 152 in pfmTrans.cxx is using the old interface still “NodePath mesh = file.generate_vis_mesh(true);”
Oops, new fix committed to pfmTrans.cxx, thanks! And I’ll be standing by for more information on the deadlock.
David
I have some new info.
The chance of deadlock seems to be proportional to the number of sounds playing.
Setting “fmod-number-of-sound-channels” to a sufficiently high number (like 1000) seems to prevent the deadlock, or at least reduce the odds to the point where I could not reproduce it, so it seems likely that it is related to recycling of the sound channels.
I am down to about a third of my code and still able to cause deadlock, I will keep at it.
David, I’ve sent you a PM with a demo which should cause the deadlock.
Great, thanks! I’ll try to check it out shortly.
David
I hate to be a squeaky wheel, but I need some grease.
Oops, sorry. Sometimes I do need a little nudge. 
David
Got it! There was indeed a bug in Panda’s prev_transform update, which could lead to a deadlock in certain situations–and you happened to be the lucky individual who found one of those situations.
I’ve just committed a fix. Thanks for the demo program, it made finding the specific problem a thousand times easier!
David
Excellent, the deadlock is gone! I seem to be getting some randomish crashes still with 3-thread setup, but I think I’ll save that for later.
The other issue is the deformation of vertices on Actors seems to be lagging 1 or 2 frames behind where the skeleton is actually at. Anything attached to an exposed joint appears where it should (for example something held in the Actor’s hand), but anything that is part of the Actor (the hand itself) has a sort of delay on it and sometimes jitters between what looks like being 1 frame behind or 2 frames behind. Of course this could be specific to my character setup since I use control joints to procedurally rotate the spine.
The random crashes are a little disturbing.
Hmm, I haven’t observed this animation lag myself; and as far as I know both vertices and joints should be synchronized. Hate to ask it again, but can you produce a simple demo program that reproduces the problem?
Thanks!
David