Discussed here too.

So far the only common thing for those freezes seem to be AMD FX CPU, or something tightly accompanying it (mainboard component - maybe integrated audio card common to all amd boards?). It's certainly not operating system (freezes on both win 7 and win 10 for me), or graphics card (I didn't go as far as to buy Nvidia card to verify this, but there are reports from nvidia users too).

Symptoms - on level transition, you will either see few frames where the game tries "fade in" effect, or just black screen. During this, the sounds will start to stutter more and more over a few seconds, after which everything goes silent and your only option is to kill the game. Which is easier said than done, because it will take several minutes to start Task manager and kill it.

Dealing with the task manager issue is easy. First, switch to another user (so the game can't keep focus and prevent other applications from coming to foreground - you don't have to do this if it is running in windowed mode) and second, don't use task manager. Or more exactly don't use the built-in one - download process explorer from Microsoft instead. Turns out that almost everything works fine during the freeze, the game only pegs one CPU core, but windows taskmanager has trouble dealing with that. My routine:
- Ctrl-Alt-Del
- Switch user (called Xadmin so he sorts last on login screen)
- run process explorer, show processes from all users and kill Solus-Win64-Shipping.exe

Workarounds for the freeze (#5 is probably the easiest and safest, and also the last I discovered. Tried that in 0.58 and it didn't seem to help, or I just didn't test it properly):
- workaround #1: stop TSP, find c:\windows\system32\xaudio2_7.dll, rename to xaudio2_7.dll_. This will disable most of TSP sounds, and will let you move past the critical part. Don't forget to rename it back to get the sounds working again, and restart again. Also, "solsave" console command or sleeping just before the critical part helps, not all area transitions have save shrine close. This helps 100%, I had a save which I was pretty much unable to load (worked in 1 ouf of maybe 30 attempts) where I tested this - worked every time without the sound.
- workaround #2: disable your audio devices in device manager. On my computer I must disable both (AMD High Definition Audio Device and Realtek High Definition Audio), which would suggest it's not an issue with specific audio driver for any of them. About the same effect as #1, and similarly time-consuming, you have a choice of messing with system32 directory or with control panel
- workaround #3: when the loading screen appears, press F10. After loading is done, you will have black screen with the bug report dialog. Wait a few seconds, cancel it and pray. It doesn't always work, but based on my limited testing it often lets the game "settle down" whatever it was doing so it can continue
- workaround #4: add -SolusNoGC -SolusLoadDelay parameters when launching the game. Suggested by devs and burried in patch notes for 1.0, and doesn't do much to help in my experience (and not supported by Galaxy)
- workaround #5: turn sound off in-game = move all sound sliders to 0%. Suggested in the Steam thread and it must be done from main menu, before loading the game. In-game it will just freeze instantly or become extremely choppy.

More details in following post.

I got bit distracted with finishing the game and came up with some new wild theories that needed to be tested, but here is the promised second part - full of tech speak to make me appear smart and unlikely to be useful to anyone except maybe game/UE4 engine devs.

I mentioned process explorer above. Aside from being able to kill the game, it also offers lots of additional info. For example it lets me view individual threads, their CPU load and stack trace. The problem in this case manifests in XAudio2_7.dll thread - stack trace during freeze is always some variant of this if game was running full screen:
ntoskrnl.exe!KeWaitForMultipleObjects+0xc0a
ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x712
ntoskrnl.exe!KeWaitForMutexObject+0x19f
ntoskrnl.exe!_misaligned_access+0xba0
ntoskrnl.exe!_misaligned_access+0x183d
ntoskrnl.exe!_misaligned_access+0x1ab7
XAudio2_7.dll!DllUnregisterServer+0x1e44c
XAudio2_7.dll!DllUnregisterServer+0x207e7
XAudio2_7.dll!DllUnregisterServer+0xd9fe
XAudio2_7.dll!DllUnregisterServer+0x77f9
XAudio2_7.dll!DllUnregisterServer+0x442c
XAudio2_7.dll!DllUnregisterServer+0x48a6
kernel32.dll!BaseThreadInitThunk+0xd
ntdll.dll!RtlUserThreadStart+0x21

I based few wild theories on it, but in past few days I finally finished the game and tried to play it in windowed mode. Turns out that stack trace gets much more interesting then. Below is only an example, it changes frequently, which means it is busy with what seems to me like valid audio stuff:
XAudio2_7.dll!OAPIPELINE::COAPReverbStereo::Process+0x132
XAudio2_7.dll!OAPIPELINE::ReverbProcess+0x4b
XAudio2_7.dll!LEAPFX::CAudioReverb::Process+0x326
XAudio2_7.dll!LEAPCORE::CSWFilter::Process+0x3d
XAudio2_7.dll!LEAPCORE::CGraphManager::ThreadProc+0x518
XAudio2_7.dll!CThreadBase::StaticThreadProc+0x42
kernel32.dll!BaseThreadInitThunk+0xd
ntdll.dll!RtlUserThreadStart+0x21

While I tried to play with audio settings, I noticed what may be another lead. Even if I turn all the sound sliders to 0%, the loading screen still has sound. It has one even when I rename Xaudio2_7.dll to something else. Which means it is some kind of video played back through other means than direct X, and the issue then would be with transition to/from the video player.

So as a last experiment, I watched how the audio thread behaves during other parts of the game (only in windowed mode, so I could see psexplorer in the background):
- UE4 logo - 2% CPU
- main menu - 2-12%, 7 most of the time
- move all audio sliders to 0 (still in main menu) - 7%, then climbs to 16.6 (max), back to ~7% after some time (~20 seconds of hard work)
- restore audio sliders - brief spike to 16.6%, lots of static noise, then back to normal ~7%
- loading game, 0.3% during loading screen, spike to 16.6% and freeze (maxchannels 16)
- able to get into the game at 12 maxchannels, audio thread at steady 0.6%, infrequent spikes to ~12%
- alt-tab out - steady 16.6% and lots of frames dropped
- alt-tab back in - down to 0.6%
- move all audio sliders to 0 - steady at 16.6%, frame drops
- alt-tab away with audio sliders at 0% - freeze

I think I have exhausted my ideas for now. The problem is not exclusive to loading screen. Lowering max audio channels helps, I wasn't able to get it to freeze at 8, but as mentioned in the Steam thread, that is awfully low. And the main cause seems to be that game is waiting for audio thread while it is busy with something. Not sure what exactly it IS doing, no sound is heard, but I think it should be idle in the first place (while alt-tabbed away and/or sound sliders at 0%, loading screen video playing...). It might be interesting to see how the thread behaves on unaffected system, but I don't have any.