Audio SDL: Video editor Sound muted without muting it #66786

New Issue

AnityEx · 2019-07-12T17:42:21+02:00

AnityEx commented

2019-07-12 17:42:21 +02:00

System Information
Operating system: Windows-10-10.0.17134 64 Bits
Graphics card: GeForce GTX 1060 3GB/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 388.13

Blender Version
Broken: version: 2.80 (sub 74), branch: master, commit date: 2019-07-11 13:50, hash: 06312c6d2d
Worked: 2.79b

Short description of error
Audio playback not making any sound

Exact steps for others to reproduce the error
add a image strip and then a mp4 video file or only the mp4 file, it just doesn't sound at all by any means
filenotworking.blend

**System Information** Operating system: Windows-10-10.0.17134 64 Bits Graphics card: GeForce GTX 1060 3GB/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 388.13 **Blender Version** Broken: version: 2.80 (sub 74), branch: master, commit date: 2019-07-11 13:50, hash: `06312c6d2d` Worked: 2.79b **Short description of error** Audio playback not making any sound **Exact steps for others to reproduce the error** add a image strip and then a mp4 video file or only the mp4 file, it just doesn't sound at all by any means [filenotworking.blend](https://archive.blender.org/developer/F7603346/filenotworking.blend)

AnityEx commented

2019-07-12 17:42:21 +02:00

Added subscriber: @AnityEx

blender-admin commented

2019-07-12 17:42:21 +02:00

#67133 was marked as duplicate of this issue

Germano Cavalcante commented

2019-07-12 22:50:08 +02:00

Added subscribers: @Sergey, @neXyon, @mano-wii

Germano Cavalcante commented

2019-07-12 22:50:08 +02:00

With the sound output through HDMI the file worked without problems.
But then I decided to try with a headset and the sound continued to come from the screen through the HDMI (while in other programs the sound came out through the headset).
So I went into Preferences->System->Audio Device and even choosing the same Device something updates and the sound goes out through the headset normally.

The problem must be related, but (I don't understand anything about this area).
@neXyon, @Sergey any idea?

With the sound output through HDMI the file worked without problems. But then I decided to try with a headset and the sound continued to come from the screen through the HDMI (while in other programs the sound came out through the headset). So I went into `Preferences->System->Audio Device` and even choosing the same `Device` something updates and the sound goes out through the headset normally. The problem must be related, but (I don't understand anything about this area). @neXyon, @Sergey any idea?

Joerg Mueller commented

2019-07-13 10:37:23 +02:00

@AnityEx which audio device/backend (OpenAL or SDL) are you using and does it work if you switch it under Preferences->System->Audio Device?

@mano-wii this sounds like a different bug, but same question for you. Switch the device/backend in the preferences and then try to switch between headset and screen to check if it has the same problem.

@AnityEx which audio device/backend (OpenAL or SDL) are you using and does it work if you switch it under Preferences->System->Audio Device? @mano-wii this sounds like a different bug, but same question for you. Switch the device/backend in the preferences and then try to switch between headset and screen to check if it has the same problem.

Sergey Sharybin commented

2019-07-13 15:07:11 +02:00

The sound plays back on both macOS and Linux for me (both default OpenAL). So doesn't seem this is anything to do with the dependency graph integration or the RC build itself.

AnityEx commented

2019-07-13 18:45:30 +02:00

@neXyon SDL Does not work at all, but OpenAl and openAl-soft do work

Germano Cavalcante commented

2019-07-13 20:31:34 +02:00

In #66786#720451, @neXyon wrote:
@mano-wii this sounds like a different bug, but same question for you. Switch the device/backend in the preferences and then try to switch between headset and screen to check if it has the same problem.

The same situation is seen with OpenAL and OpenAL-Soft.
If I load Blender with the headset already plugged in. The sound comes from the headset.

SDL is mute both on the headset and on the screen.

> In #66786#720451, @neXyon wrote: > @mano-wii this sounds like a different bug, but same question for you. Switch the device/backend in the preferences and then try to switch between headset and screen to check if it has the same problem. The same situation is seen with `OpenAL` and `OpenAL-Soft`. If I load Blender with the headset already plugged in. The sound comes from the headset. `SDL` is mute both on the headset and on the screen.

Joerg Mueller commented

2019-07-13 22:33:03 +02:00

Added subscriber: @LazyDodo

Joerg Mueller commented

2019-07-13 22:33:03 +02:00

Okay, from what I gather from both of you now is that OpenAL works, but SDL does not on Windows. @LazyDodo can you check if SDL works on windows or if it's not? Maybe we need a library update on windows?

As for the plugging in headsets @mano-wii, there's nothing we can do. The only thing you could try to do is to open an issue for OpenAL soft, there is already a similar one as far as I checked: https://github.com/kcat/openal-soft/issues/291

Okay, from what I gather from both of you now is that OpenAL works, but SDL does not on Windows. @LazyDodo can you check if SDL works on windows or if it's not? Maybe we need a library update on windows? As for the plugging in headsets @mano-wii, there's nothing we can do. The only thing you could try to do is to open an issue for OpenAL soft, there is already a similar one as far as I checked: https://github.com/kcat/openal-soft/issues/291

Germano Cavalcante commented

2019-07-17 23:33:41 +02:00

Added subscriber: @TheKlikluk

Ulysse Martin commented

2019-07-18 06:05:09 +02:00

Added subscriber: @you.le

Ulysse Martin commented

2019-07-18 06:05:09 +02:00

I just tested on windows. By default, openAL is selected on my computer and the sound plays normally. If I select SDL, the sound is not played whereas the sound is played both with openAL and SDL in 2.79b. When I replace 2.8 SDL2.dll with 2.79b SDL2.dll, the sound works correctly both with openAL and SDL in 2.8. Then it seems to come from SDL2 lib update in 2.8 I think

Ray molenkamp was assigned by Joerg Mueller

2019-07-18 08:43:35 +02:00

Philipp Oeser changed title from ~~Video editor Sound muted without muting it~~ to Audio SDL: Video editor Sound muted without muting it

2019-09-03 14:21:33 +02:00

Richard Antalik commented

2020-01-03 01:24:53 +01:00

Changed status from 'Needs Developer To Reproduce' to: 'Confirmed'

Richard Antalik commented

2020-01-03 01:25:41 +01:00

Added subscriber: @iss

Richard Antalik commented

2020-01-03 01:25:41 +01:00

I should have clarified, thatI tested this on windows

Ray molenkamp commented

2020-06-03 15:38:31 +02:00

In #66786#720955, @neXyon wrote:
Okay, from what I gather from both of you now is that OpenAL works, but SDL does not on Windows. @LazyDodo can you check if SDL works on windows or if it's not? Maybe we need a library update on windows?

Audaspace request AUDIO_S16SYS , SDL goes best I can do is AUDIO_F32LSB and audaspace goes , FINE no audio.

the SDL documentation says

If obtained is NULL, the audio data passed to the callback function will be guaranteed to be in the requested format, and will be automatically converted to the actual hardware audio format if necessary. If obtained is NULL, desired will have fields modified.

Did a quick test, and it indeed restored audio with SDL, but most of the SDLDevice ctor code can/should be removed so i'll leave it to @neXyon to do a proper cleanup there.

> In #66786#720955, @neXyon wrote: > Okay, from what I gather from both of you now is that OpenAL works, but SDL does not on Windows. @LazyDodo can you check if SDL works on windows or if it's not? Maybe we need a library update on windows? Audaspace request `AUDIO_S16SYS` , SDL goes best I can do is `AUDIO_F32LSB` and audaspace goes , *FINE* no audio. the [SDL documentation ](https://wiki.libsdl.org/SDL_OpenAudio) says ``` If obtained is NULL, the audio data passed to the callback function will be guaranteed to be in the requested format, and will be automatically converted to the actual hardware audio format if necessary. If obtained is NULL, desired will have fields modified. ``` Did a quick test, and it indeed restored audio with SDL, but most of the `SDLDevice` ctor code can/should be removed so i'll leave it to @neXyon to do a proper cleanup there.

Ray molenkamp removed their assignment 2020-06-03 21:24:08 +02:00

Joerg Mueller was assigned by Ray molenkamp

2020-06-03 21:24:08 +02:00

Joerg Mueller commented

2020-06-04 17:28:07 +02:00

Ah, we're on SDL 2 now, and SDL 2 has new audio sample formats. Originally, the SDL backend was implemented for SDL 1.2 which had only 8 and 16 bit sample formats . If we're using SDL 2 now, it makes sense to update.

@LazyDodo can you please elaborate why and which code of the ctor should be removed? I think it should rather be extended to support the new sample formats... So, please try if this patch works for you: sdl_2.diff

Cheers

Ah, we're on SDL 2 now, and SDL 2 has new audio sample formats. Originally, the SDL backend was implemented for SDL 1.2 which [had only 8 and 16 bit sample formats ](https://www.libsdl.org/release/SDL-1.2.15/docs/html/sdlaudiospec.html). If we're using SDL 2 now, it makes sense to update. @LazyDodo can you please elaborate why and which code of the ctor should be removed? I think it should rather be extended to support the new sample formats... So, please try if this patch works for you: [sdl_2.diff](https://archive.blender.org/developer/F8576903/sdl_2.diff) Cheers

Ray molenkamp commented

2020-06-04 17:37:15 +02:00

Given SDL is guaranteed to give us the format we want as long as we don't give it an opportunity to tell us otherwise, i was planning to go with

diff --git a/extern/audaspace/plugins/sdl/SDLDevice.cpp b/extern/audaspace/plugins/sdl/SDLDevice.cpp
index 603e16001b8..fe6deb54b24 100644
--- a/extern/audaspace/plugins/sdl/SDLDevice.cpp
+++ b/extern/audaspace/plugins/sdl/SDLDevice.cpp
@@ -58,7 +58,7 @@ SDLDevice::SDLDevice(DeviceSpecs specs, int buffersize) :
 
 	m_specs = specs;
 
-	SDL_AudioSpec format, obtained;
+	SDL_AudioSpec format;
 
 	format.freq = m_specs.rate;
 	if(m_specs.format == FORMAT_U8)
@@ -70,21 +70,9 @@ SDLDevice::SDLDevice(DeviceSpecs specs, int buffersize) :
 	format.callback = SDLDevice::SDL_mix;
 	format.userdata = this;
 
-	if(SDL_OpenAudio(&format, &obtained) != 0)
+	if(SDL_OpenAudio(&format, NULL) != 0)
 		AUD_THROW(DeviceException, "The audio device couldn't be opened with SDL.");
 
-	m_specs.rate = (SampleRate)obtained.freq;
-	m_specs.channels = (Channels)obtained.channels;
-	if(obtained.format == AUDIO_U8)
-		m_specs.format = FORMAT_U8;
-	else if(obtained.format == AUDIO_S16LSB || obtained.format == AUDIO_S16MSB)
-		m_specs.format = FORMAT_S16;
-	else
-	{
-		SDL_CloseAudio();
-		AUD_THROW(DeviceException, "The sample format obtained from SDL is not supported.");
-	}
-
 	create();
 }

Given SDL is guaranteed to give us the format we want as long as we don't give it an opportunity to tell us otherwise, i was planning to go with ``` diff --git a/extern/audaspace/plugins/sdl/SDLDevice.cpp b/extern/audaspace/plugins/sdl/SDLDevice.cpp index 603e16001b8..fe6deb54b24 100644 --- a/extern/audaspace/plugins/sdl/SDLDevice.cpp +++ b/extern/audaspace/plugins/sdl/SDLDevice.cpp @@ -58,7 +58,7 @@ SDLDevice::SDLDevice(DeviceSpecs specs, int buffersize) : m_specs = specs; - SDL_AudioSpec format, obtained; + SDL_AudioSpec format; format.freq = m_specs.rate; if(m_specs.format == FORMAT_U8) @@ -70,21 +70,9 @@ SDLDevice::SDLDevice(DeviceSpecs specs, int buffersize) : format.callback = SDLDevice::SDL_mix; format.userdata = this; - if(SDL_OpenAudio(&format, &obtained) != 0) + if(SDL_OpenAudio(&format, NULL) != 0) AUD_THROW(DeviceException, "The audio device couldn't be opened with SDL."); - m_specs.rate = (SampleRate)obtained.freq; - m_specs.channels = (Channels)obtained.channels; - if(obtained.format == AUDIO_U8) - m_specs.format = FORMAT_U8; - else if(obtained.format == AUDIO_S16LSB || obtained.format == AUDIO_S16MSB) - m_specs.format = FORMAT_S16; - else - { - SDL_CloseAudio(); - AUD_THROW(DeviceException, "The sample format obtained from SDL is not supported."); - } - create(); } ```

Joerg Mueller commented

2020-06-04 21:08:28 +02:00

This changes behavior... So far we had it take the closest possible configuration, in the hope we can support it. That's the more user friendly solution, especially when people don't want to bother with the details of these settings.

Also your patch won't solve the issue, SDL still wouldn't work with this, since apparently the audio device in question only supports the float sample format, which is not implemented in this patch.

Did you try my patch? If not please do!

This changes behavior... So far we had it take the closest possible configuration, in the hope we can support it. That's the more user friendly solution, especially when people don't want to bother with the details of these settings. Also your patch won't solve the issue, SDL still wouldn't work with this, since apparently the audio device in question only supports the float sample format, which is not implemented in this patch. Did you try my patch? If not please do!

Ray molenkamp commented

2020-06-04 22:56:22 +02:00

Also your patch won't solve the issue, SDL still wouldn't work with this, since apparently the audio device in question only supports the float sample format, which is not implemented in this patch.

We don't need to, SDL does the conversion for us

Did you try my patch? If not please do!

Not yet, I'll try to do so tonight

> Also your patch won't solve the issue, SDL still wouldn't work with this, since apparently the audio device in question only supports the float sample format, which is not implemented in this patch. We don't need to, SDL does the conversion for us > Did you try my patch? If not please do! Not yet, I'll try to do so tonight

Joerg Mueller commented

2020-06-05 10:21:51 +02:00

You're right, it could do the conversion. It may also change the number of channels and resample to a different sampling rate though. All of this can possibly deteriorate the quality. For example, we want to render 3D audio to the correct speaker setup that SDL outputs with and not to a wrong one and then SDL somehow changes the channel configuration resulting in a suboptimal listening experience. That's why we would rather do these things ourselves rather than having SDL do it.