This seems like a terrible solution, since I imagine plenty of people have python installed alongside Blender

Honestly, I took everything python related out of my system variable path in my environment variables. I had already uninstalled python, but its files still existed on my hard drive and so did the system variable pointing to them. (I believe Anaconda which installed python 3.7 for me automatically adds this pointer to the path)

Files from the appdata directory may be loaded because of this:
https://docs.python.org/3/library/site.html#site.USER_SITE

Judging by the process monitor, I assume we will conclude that Blender was loading python scripts from a path library instead of its default library?

I've scrubbed every instance of python on my computer and removed all python pointers in my environment variables and path, then restarted for good measure.

Don't know that program at all, but here's what I could find when trying to import numpy, it seems to still be sourcing from another installation of python, but you might know better.

can you trace the process with process monitor and validate that the _multiarray_umath.cp37-win_amd64.pyd file is actually being read from the blender folder and not some other place?

Same exact thing with 2.83, file is included, import fails. =c

I've downloaded the portable to desktop, unzipped and verified there is indeed the numpy multiarray as seen in the attached images (if I can attach them).

It may be worth trying Blender 2.83, which has changes to ignore Python environment variables:
https://builder.blender.org/download/

Don't Install Blender, try the portable build instead.
https://www.blender.org/download/Blender2.82/blender-2.82-windows64.zip/
Open the folder and check to see if
_multiarray_umath.cp37-win_amd64.pyd

the blender_debug_log.cmd batch file has this in it

I have not updated my PYTHONPATH environment variable since that github post, I can try that in a moment.

@Evan Wilson (EAW) the debug batch files reset the PYTHONPATH var, i'm 100% sure it is not set when blender starts with those.

First, I copied my python37 site-packages into my Blender2.8.2 python folder (the second option in the link you provided). This did not work, so I proceeded to the first option.

Opened blender via blender_debug_log.cmd
went to scripting tab
same error as mentioned above when trying

import aud

Can't repro on windows with the official 2.82 or latest master

@Sebastian Parborg (zeddb) Thank you all for your awesome and hard work!

Thanks for the quick reply :)

@Sebastian Parborg (zeddb) sorry, wasn't been an issue to me since the last 2 stable builds at least. Thanks.

Is this still an issue in the latest version? https://builder.blender.org/download/

I will merge this report to another one, because it is the same underlying issue.

Okay, I had a close look at those configuration files and how they work. It's impossible to get the old behavior of OpenAL Soft of before the introduction of ambisonics. So there's nothing we can do unfortunately to make them work the same.

After setting scene audio to 7.1ch I got correct render.

In T58153#861447, @Richard Antalik (ISS) wrote:

No audio with SDL, havent tried workaround.

In T58153#861447, @Richard Antalik (ISS) wrote:

No audio with SDL, haven't tried workaround.

When I am here, I may as well do the thing..

I looked into this:

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

Can confirm in a buildbot build.
(havent built with JACK myself yet, but...confirming for now)

I should have clarified, thatI tested this on windows

@Sybren A. Stüvel (sybren) nice find, thanks! I've also fixed this upstream. For consistency I'll also commit my fix to blender so that the audaspace code stays consistent. Less than 24 hours to review a patch, even though it's small, is not enough for a volunteer that is not full time employed to work on Blender. I usually only get to work on it during weekends and then not all of them are available either.

I've committed the above code, as it does fix the crash (and not crashing is better than crashing).

The cause of the crash is a careless cast from int64_t to int. The patch below fixes the crash and IMO is generally a better approach than the existing code, but the root cause probably lies somewhere else. I found that in SequenceHandle::updatePosition(float position) at frame 172 (the crashing frame), the position is 5.733313 where as m_end is 5.733333. This seems to suggest floating point errors are occurring somewhere.