Page MenuHome

Preview mono audio not the same as render
Open, NormalPublic


System Information
Operating system: Windows 7
Graphics card: Vega 64

Blender Version
Broken: 2.80 Beta 43e7c5dd434 29/11/2018

Worked: 2.79b release

Short description of error

Preview playback of audio strips set to mono don't behave the same way compared to 2.79b.

2.80b renders the audio channels correctly but doesn't preview them the same way as the render.



Exact steps for others to reproduce the error

May require a surround speaker setup


Listen to the playback differences with mono checked and unchecked.



Event Timeline

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?

Sorry, a complete derp on my end...

(note: My full system specs are on my profile)

Here is my audio setup:

Audio device:Realtek® ALC1150 8-Channel High Definition Audio CODEC (on-board audio)
Audio Driver Version:

I use the default OpenAL, but I tried with SDL, but I get nothing. The animation plays, but there is no audio. (both in 2.79 and 2.80)
I disabled all enhancements / sound effects.

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

Please also try a 2.79 version from the build bot here:

I suspect that the problem with OpenAL is caused by a library update and thus should exists there as well. The precise change in OpenAL soft that I'm suspecting is here: - it basically removes the front speaker from the 5.1 setup and that causes the audio rendering to differ between playback and output.

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:

surround51 = <<FILE>>

(see and for <<FILE>> you have to fill in the filename where you downloaded this file:

This should bring back the configuration before the library update.

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?

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?

At what point does this become a Blender issue? I assume the way Blender handles mono audio panning is unique.

More testing...

This is a simple switch from mono checked to unchecked.
Left is the 2.79 release, right is the latest builds.

This is a Surround Pan left is the latest builds, right is the 2.79 release.
There is a lot of leaking between the channels

So my suspicion seems to be correct. The difference in playback is cause by the changes in OpenAL soft which now uses 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:

Christopher_Anderssarian triaged this task as Normal priority.Jan 2 2019, 5:17 PM

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

Is this still an issue?
If yes, Should I keep VSE tag?
I am trying to cleanup workboard a bit..

Yes, this is still an issue. It's a minor inconvenience for me, but others may find it a blocker in their work flow.

@Richard Antalik (ISS) Out of curiosity, are going to categorize tasks like in BF Blender: 2.8 (here) or Code Quest (here)?
You can further categorize them by when they should be implemented or by specific areas or by both.
Feels to me wasted functionality of phab, but I thought I'd let you know/decide :)

Right now I am focusing on bugs.
If there is VSE bug not tagged, I guess other devs will relay this to me If I don't catch it.

I can/should look at approved design decisions made in code quest, but now bugs are the priority.