Thank you all involved!

I can confirm this problem. I was about to report the same problem but I found this report... so I'm here confirming the exact same issue with audio playback. I tested different audio methods in the blender system preferences (JACK, SDL, OpenAL...) I'm on Linux Ubuntu 20.04.1 LTS

I see that now the problem is solved:

This is awesome! I can't express how nice is this... to be able to follow a bug begin smashed! Everything is working so nice now! Thank you all!!! Special thanks to @Sebastián Barschkis (sebbas) ! You're doing an awesome job! Thanks!

@Iago Diogo Vasconcelos Mota (IagoMota) I'm testing here with current Master (2.90 alpha) didn't test with 2.83.
With 2.90 alpha the only thing that still happens is the vorticity spreading the smoke, but I'm not sure if this is the correct behavior, maybe this is the way it works and we need to keep really low values, I think it is very exaggerated with 0.3 but not sure...

The force field example is working fine to me. The smoke is immediately influenced by the force.

@Sebastián Barschkis (sebbas) Do you think that it is possible to keep the velocity data in the cache(I don't know exactly how it works so ignore my guessing)?
Also, what do you think that is causing the strange behavior with the smoke flow force field over particles? Do you know how to bring a similar behavior as before(old smoke system) or even better as discussed here?
Or the smoke force field behavior is a separate issue here?

This bug seem to be squashed to me.. I tested the attached files and they are working fine to me. Can you confirm this @Iago Diogo Vasconcelos Mota (IagoMota) ?

Thanks, @Sebastián Barschkis (sebbas) I just compiled blender now after your additional fix, and everything related to this report is working fine now! The slowdown in time scale is taking gravity and forcefields into account. THANK YOU!
There's something weird already with forcefields but I will open a separate report. The animated "Max Distance" under "Fallof" are affecting particles(SPH) and liquid(MANTAFLOW) even outside of radius scale, there's full influence inside the Max Distance radius but outside of the radius there's still a little of influence, it's not totally 0.

Now there's an even stranger thing happening... see the attached file, please. Also, after checking the file please test the minimum timestep value of the domain, default is 1 change it to 4(same value as maximum) and the result seems to be slower with time scale 1...

Please, check the blend file attached in the comment that I said about Force Fields... after checking this problem with forcefields I see the same problem still happening...

@Sebastián Barschkis (sebbas) I compile blender from Master. I was using the Master before your commit 6400f54b4cc6 but I tested now, compiled after the commit and I can confirm that it's working fine.
However, there's something weird when I animate the emitter density value. Just check the attached file hitting play, wait until frame 50 and stop the playback(you should see the smoke disappearing). Go back to frame 1 and play cached frames you can see the right result(the smoke disappearing) but when the playback reaches frame 51, uncached frames, the smoke appears again...

What I found in this file is that if you change the density value from the emitter(sphere) from 3 to default 1 the smoke works ok for me. When I try to change the density from the emitter the smoke explodes...
With domain resolution to 64 and replay cache mode, the smoke explodes immediately at frame 1... when changing the emitter density to 1 it works fine

Great work! Thank you SO MUCH! You are an awesome team! But special thanks to sebbas! Thank you! thank you! thank you!

Any news on this report? Is Someone checking here?

Force Fields are not working also...
Note in the attached file that right when the timestep is slowing down the liquid particles starts to go crazy, their velocity color goes red immediately...
The above mentioned SPH particles behavior takes into account the force fields and gravity as expected, keeping the motion of the particles and only slowing down the timestep.

The expected behavior is the same as in the SPH Particles example here:

Well, I found a very handy feature inside mantaflow domain and it’s the viewport display setting. It turns the smoke velocity field visible in the viewport for a better understanding of what is going on.
In this gif example, you can see the velocity field being represented in the viewport. I’m wondering if it’s possible to see all the blender force fields like this.

Well I found a very handy feature while investigating this bug and it's the viewport display setting inside mantaflow domain. The Debug Velocity option reveals that the velocity is calculated while the simulation runs but this information seems to be "released" or "cleaned" after the the smoke frames are baked.

I also started a discussion about "exposing"(I'm not dev and don't know if it's a simple "expose" case) more properties from gas sim to be used by the smoke flow force field.
You can check it here:
https://devtalk.blender.org/t/update-smoke-flow-force-field/12761

I also reported this bug, merged here, didn't know about this report... sorry. I just want to tell my experience with this "inconsistency" in the smoke flow force field.
1 - While baking the smoke sim with replay cache mode the smoke flow force field seems to work ok(but I still find something strange... it's hard to set up and make it work well but this is another thing separated from the problem from this report...)

Thanks @Brecht Van Lommel (brecht) I was able to reach the right channel to discuss about this idea.
https://devtalk.blender.org/t/update-smoke-flow-force-field/12761/2

About the feature request... I know that this is not the place... but where can I suggest this new feature?

I can confirm it. I was about to report the same bug but found this report here. Thanks for reporting. Actually not only opacity... almost everything that I tested didn't update during the playback but seems to render ok with CTRL + F12. The result rendered file is fine with all animations.

Will this issue be tackled before the 2.81 release? Or will this wait for manta-flow integration?

It seems to me that the "intern domain area" is not in sync with object used as domain. When I apply the rotation the simulation works but the "internal domain area" is respecting the global axis and adjusts its size to bound the object domain, acting like a bounding box...

In my tests here I just cleaned the cache and the new frame rate works as it should. What happens is if you cache rigidbody at 24fps and then change the frame rate to another value like 60fps the playback will use that cached frames at 24fps and playback that cache with the new 60fps, resulting in a faster playback only on that cached(at 24fps) section of the timeline. that's why you should clean your cache (just changing some physics values) when you change the frame rate of your project.
What could help here is if you change the fps value it could clean the cache for you... but I'm not sure if it "should" clean the cache...

Thanks for the fix, Bastien Montagne! It's working as always now.
I'm so glad! The blender support is amazing because of you guys.

I also tried the attached file with the 2.80 official release from the blender.org site and it works as expected:

I also tried with a build bot build from today and I have the same issue with objects also.
Note the red lines indicating that I'm in the local axis rotation mode but it not happening... They rotate in global.

Looks like you have a working build...
Here I have this result with 135°:

I tested here and there are no more particles missing BUT there is one setting that is not yet following the switch from emitter > hair > emitter. It's the "render as" dropdown in the particle render tab. It's "halo" when particles are "emitter" mode and it changes to "path" in "hair" mode but when you change back to "emitter" mode the "render as" remains as "path". It's not showing in the viewport as path because of this render type needs a cached particle system. You can confirm that by repeating the steps from the bug report but at the end just bake the simulation to see the "paths" in the viewport appearing. I think that this render type setting should follow the system default and change back to "halo" when the mode is switched back to "emitter".

Wow! This was the fastest fix I ever see! Thanks for the blazing fast response, I really appreciate! Thanks! Now I can continue my work.

Thanks, Sergey and dev team! God bless you all!

After some more tests I think I found where the bug is... When I disable the "Auto Smooth" option under mesh property panel the glitch is gone and everything works fine like in the workbench engine... I still don't understand it since I'm not a developer but I know that it's related with "auto smooth" option.

Yes, I can confirm, I built blender again after the "FIX commit" and it's working fine now. This bug is gone! On more for the list o vanished bugs! Thanks! It's resolved!

I see this problem with factory startup also...
Here is a simple .blend and a screenshot.

Same issue reported on T58892.
Ok, I'm not sure if I'm allowed to do this here... let me know...
I have tested this one and I found that to solve this you need to change particle type manually. When you change the particle type to hair the particle type is set to "path" on "render as" option in the render dropdown inside the particle system. You need to set the particles to halo again and they will show up in the viewport again.

Ok, I'm not sure if I'm allowed to do this here... let me know...
I have tested this one and I found that to solve this you need to change particle type manually. When you change the particle type to hair the particle type is set to "path" on "render as" option in the render dropdown inside the particle system. You need to set the particles to halo again and they will show up in the viewport again.

I have the same problem on Ubuntu 17.10, I was able to build without problems before the commit that upgrades numpy.
I also have this warning when building blender that was not present before some recent python related commits:

This is working now. On cycles and blender internal.
Tested on Linux.
Thanks!

In T51012#424012, @Germano Cavalcante (mano-wii) wrote:

Are you sure this worked before?
I have tested here and it seems like, it always worked as a point. (What is strange considering the Curve option)`

Maybe you are confusing with the Curve Guide type. No?