Tried to reproduce, however in output settings value of Video Codec item is empty.
What codec do you have set?

Fixed by 3610f1fc43d0

No worries, it's a relatively minor inconvenience and does not affect the final render (or mixdown).

So my suspicion seems to be correct. The difference in playback is cause by the changes in OpenAL soft which now uses ambisonics (https://en.wikipedia.org/wiki/Ambisonics) based surround sound. Originally, I implemented Blender's speaker mapping based on OpenAL soft. That's why so far they have been the same. Ambisonics is actually better and ideally Blender would also go this direction for 3D sound. Unfortunately, I don't have the resources for this development right now, it's more a long term goal. If you need an short term solution, please use the configuration files as I have mentioned them. There are also ambdec files for different speaker setups including 7.1 here: https://github.com/kcat/openal-soft/tree/master/presets.

More testing...

Okay, okay... so....
I've got 8 channels (speakers) so I just leave the sound preferences at 7.1 and adjust the scene audio to the project's need (as you know from T49241#489952) will the configuration you suggest work for 7.1?
And will the panning stay the same as in 2.79?

Yep, I'm getting the same result with daily build: 2.79 Windows 64 bit December 29, 01:50:18 -111179beb0b1-.
I also confirmed this is happening in Linux (the nono audio not behaving in the same way as 2.79).
I'm still having trouble getting SDL to work. I've spun up an old Debian VM (with 2.80 Beta -266b1e2cdbc1-) with no drivers manually installed and Blender crashed upon switching to SDL.
Do audio drivers need to installed for this to work?

Finally, if you can confirm that this change in OpenAL soft is the cause, there's one thing you can do to get the same output in playback as in rendering. You have to create an openal soft configuration file named $HOME/.alsoftrc and have the following content:

Please also try a 2.79 version from the build bot here: https://builder.blender.org/download/

Hmm, SDL should work though, can you play around with the settings a bit? The sample rate 48 kHz should work fine, you can try changing the number of channels in the user preferences. Also please try setting the environment variable SDL_AUDIODRIVER to dsound or waveout and check if that helps to get SDL to work. See https://sdl.beuc.net/sdl.wiki/SDL_envvars#head-9ae11b2daf93dc3706eccf15cbf26eb6235ac634

Sorry, a complete derp on my end...

Hey, what audio backend/device are you using? OpenAL? If so, does it work with SDL? What operating system are you on? Do you have an audio driver installed? If so, which one and which sound card do you have if any?

Will have to review this in context of font selection for text FX - Brecht modified linking / unlinking

@Joerg Mueller (nexyon) Polite Nudge...

@Joerg Mueller (nexyon) Mind having a look?

@Joerg Mueller (nexyon) the issue was always present in this system.

I have no idea what to do about that either. Sounds like a weird Mac problem. I'd like to know if it worked before on this system? If yes, what changed? MacOS update? Blender update? Is there an older Blender version that works?

not sure what we can do here, @Arto Kitula (akitula)? or maybe @Joerg Mueller (nexyon) also has some ideas?

The issue (or some kind of a/v related issue) is still happening, this time even more weird, I couldn't playback a youtube video from chrome until close Blender, then suddenly worked.

I didn't change the default Sound Configuration which seems to be OpenAL.
What should be the right Sound setting for this machine to use with Blender?
Meanwhile I'll try with SDL and None settings to see if the problem persist.
Thanks!

That sounds more like an audio driver/system issue… Did you try with all the various audio outputs Blender supports (OpenAL, SDL, …)? In user preferences, System tab.

Yeah, we actually have a system to 'pass' that kind of data across undo steps, it’s just being ignored by BKE_sound_load()...
Will fix (and slightly refactor bSound flags, there is at least one flag here that is purely runtime and should be a tag ;) ).

Here's a simplified .blend that still crashes. It has a single image (used as a 360-frame image strip) and 2 sound files.
I don't know how to bundle the image into the .blend file, but the 2 sound files seem to be there.
I'll add the image file here, and you can re-add the image strip.

Cant reproduce, renders fine here.

@Cerbyo (Kite)
https://docs.blender.org/manual/en/dev/data_system/scenes/properties.html?highlight=scene%20audio#audio

In T54418#495968, @Joerg Mueller (nexyon) wrote:

4. You can set the scene audio channels under properties -> scene -> audio -> format -> audio channels.

3. You have to know what you want to do... If you can do the audio editing in Blender, do it there, if not use some other program.

@Cerbyo (Kite) I'll post on the BSE.

So this is what I'm getting from all this:

1. The 32 channels of the blender vse are called channels but they aren't the same as audio channels (aka mono being 1, stereo 2 channel).

Maybe it does make sure that these settings are controlled and saved in the file. At least this will keep things consistent if a studio is having multiple people us one file. Between 1 & 3, I think I like 3 best.

Looking at T54115 it sounds like system settings and not workspace settings are where the current user settings should go to, since these settings are hardware specific.

In T49241#491006, @Joerg Mueller (nexyon) wrote:

Your distinction between the three types of settings is pretty clear. Regarding the user preferences there is no discussion, they are stored system wide and not blend file wide. Playback will always have to happen within the bounds of the user settings. For example, if your user settings are stereo, you simply can't playback 7.1, it will be mixed down to stereo, as in @Christopher Anderssarian (Christopher_Anderssarian)'s laptop example.

Now for scene and encoding (stored in the blend file) there are three options that I see right now in terms of format (=channels) and rate (=sample rate):

1. Keep the settings where they are and use them for encoding and playback (an option here would be to duplicate the input elements in the encoding panel, but I wouldn't remove them from the scene settings).
2. Move the values to encoding and for playback always use the user settings.
3. Duplicate the values and have different encoding and playback settings.

If your source audio file isn't using the full dynamic range of the amplitude, it is basically wasting quality. Most audio files have a dynamic range of 16 bit. If you have to double the amplitude (volume in blender = 2), you are already wasting one of these bits. At 10, you are already wasting more than 3 bits. So for any recording engineer the goal is to utilize the whole dynamic range to not lose any quality during recording. When you have a file that doesn't use the full dynamic range, then increasing the volume in audacity instead of blender doesn't make any difference in terms of outcome, so you could just do it in blender directly. The problem is of course that you don't by how much, so using audacity makes sense after all. As soon as you normalized the volume in audacity, you are using the full dynamic range, going higher in blender then leads to clipping.

I don't understand why you said

Ok, then I'll close this. There is no difference in processing of the strips between mixdown and rendering. Not even to playback, the only difference there is that the user settings are used in terms of channels and sample rate.

In T54418#492826, @Joerg Mueller (nexyon) wrote:

...This approach is volume preserving and is also what OpenAL does, though Blender doesn't use OpenAL to do this in the sequencer.

Ok, changing the number of channels is another story. Blender supports surround sound (=more than two channels) in contrast to Audacity.

Thanks @Joerg Mueller (nexyon) for the clarification.

Ok, there is a lot going on here and a lot of the information written here is just plainly wrong. Let me try to summarize: you're setting the volume of an audio strip to 10 and get an output that is clipped. Well, that's expected. I tried this and whatever I do, it always sounds the same - whether I play back in Blender (SDL or OpenAL), mix down (wav or flac) or render to a video (matroska, PCM). In that sense, I cannot reproduce the bug report.

In T54418#491941, @stephen paschke (paskperfect) wrote:

I did my first serious non-linear editing with other linux-based editors, that required rendering of audio and video separately, and then muxing them together for the final file. Computers have gotten better and faster, so sometimes it is easy to forget that there are ways to put less stress on the way data flows in computer hardware.

I like your idea, Cerbyo (Kite).
Starting with the best sound possible, and adjusting volumes downward (by ear, or numbers) seems reasonable, if you are trusting of your hearing. But I have been working with blender for many years, and would caution you to stay vigilant, with visual ques (from the Audacity graphical images), as well. Projects (in Blender) that have many small clips moved around, and key-frame adjustments to volume levels, can be taxing on some computer processors.

Edit: I recorded the vse playback in audacity of a 1.0 volume strip (one I had doctored up in audacity all nicely that was imported into the vse as a single strip). And lined it up with the mixdowned version of that strip back in audacity. Playback in audacity: The recorded playback sounded clearer and better, the mixdowned version had a waveform that was clipping in some spots. EVen if i was recording the vse playback at a lower volume, thus not getting clipping, who cares! there is no way to change the volume/amplitude of the mixdowned version to get it to sound as good, cause it clipped. I would have to manually do the scene method to change the volume.....and that has countless problems to begin with including the ending audio getting cutout (so u have to put an extra strip in). I'm just gonna record the playback for now on in the vse and use that. I might try my method below still, but seriously I can see so many things going wrong....why bother. And here's what I don't get: the 1.0 volume strip was from a mixed down audacity file I have open right now....and there is noooooo clipping, and the waveform is much lower than the mixdowned waveform!?!?? THAT makes no sense based on my previous tests and the test below that say a 1.0 imported waveform will export as the same volume/waveform level. Contradictions abound. Again this was .flac 1 accuracy.
My only thoughts to leave on is the OpenAL vse SDL might have something to do with all this. As I stated earlier, OpenAL sound so much clearer on vse playback than SDL. Perhaps OpenAL is not making it into the rendering process though, thus I'm hearing some kind of jumbled SDL output? Perhaps OpenAL is applying some unknown amazing effect in the VSE playback and its making it all amazing sounding?!? But I haven't been able to recreate by recording SDL vs OpenAL via audacity capture. Regardless, I don't know anymore, I'll stick with what is working over what is supposed to be working.