- User Since
- Feb 4 2009, 8:52 AM (595 w, 5 d)
Sat, Jun 27
Looks good, not ideal as discussed in T49241, but probably better than what we have currently. :)
Sat, Jun 13
Jun 5 2020
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.
Jun 4 2020
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.
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.
May 22 2020
May 18 2020
Also it looks like this glitching happens during one or maximum 2 playback cycles and only if camera perspective is changed.
May 3 2020
Mar 30 2020
Mar 28 2020
Mar 23 2020
This patch should fix the issue.
Feb 21 2020
All looks good! I'll also port it upstream.
Jan 30 2020
Okay, I had a close look at those configuration files and how they work. It's impossible to get the old behavior of OpenAL Soft from before the introduction of ambisonics. So there's nothing we can do unfortunately to make them work the same.
Jan 29 2020
Jan 25 2020
The crash happens as follows, when you use JACK and AV-sync, JACK transport is enabled meaning that JACK will call the sound_sync_callback, which down the road
Dec 21 2019
This is a known issue and a limitation of how pitch animation works and has been there since Blender had pitch animation, even before my time (i.e. 2.49 and earlier). Unfortunately, this is a really hard problem and not easily solved, it would need a completely different architecture of the audio system which doesn't fit well with Blender's animation system. I've written about this elsewhere a couple of times already.
Nov 22 2019
@Sybren A. Stüvel (sybren) nice find, thanks! I've also fixed this upstream. For consistency I'll also commit my fix to blender so that the audaspace code stays consistent. Less than 24 hours to review a patch, even though it's small, is not enough for a volunteer that is not full time employed to work on Blender. I usually only get to work on it during weekends and then not all of them are available either.
Nov 17 2019
Thanks for this patch. I resolved the issue differently though, just in case files with even more channels show up in the future!
Nov 6 2019
@Sergey Sharybin (sergey): So starting a job that shows a progress bar is not possible after file selection?
Since I didn't get a response from you anymore on blender.chat and I don't have the required background knowledge, I'll assign this bug to you @Sergey Sharybin (sergey).
Since this is a feature request that has been open for quite a while now, I archive it.
Closing, bug is not present in 2.8.
Archiving, since there was no further response.
@Christopher_Anderssarian have you tried the speaker setup configuration files as I mentioned?
Oct 3 2019
As I wrote in T59540#588156 doing a callback for every sound sample is way too slow. We could consider it for every buffer if it is fast enough and it is possible. The issue here is that the depsgraph would need to provide the functionality to get the value of a single property for a specific time. I'm not sure if it can easily do that?
Let me revise what I wrote in my previous comment, my bad memory caused some wrong statements:
If I'm right this issue is the same as T52472 and it was my mistake that I didn't correctly backport this to upstream audaspace and this caused a reintroduction of the bug. Please check if it's fixed for you now! There is some more explanation in the other bug report.
Oct 1 2019
The interpolation is not a bug per se. The audio animation system is evaluated once for every read, so you basically get nearest neighbor interpolation for your buffer size. The buffer size can be adjusted during audio export as you correctly noticed. When rendering a video though, the audio system is called once per (image) frame so you get this issue here. I think having a general option in the render settings would be a good idea to mitigate the issue.
Sep 28 2019
There's nothing we can do here, it's an issue of OpenAL. You could report it upstream.
Jul 18 2019
Jul 13 2019
Okay, from what I gather from both of you now is that OpenAL works, but SDL does not on Windows. @Ray molenkamp (LazyDodo) can you check if SDL works on windows or if it's not? Maybe we need a library update on windows?
@AnityEx (AnityEx) which audio device/backend (OpenAL or SDL) are you using and does it work if you switch it under Preferences->System->Audio Device?
Jul 10 2019
I just git bisected this, commit a4c907af7760a980c09e46feed92bd93a0906ba9 causes jack transport synchronization to be almost completely broken.
Jul 7 2019
After spending some time playing around with this I can make the following observations:
Jun 29 2019
That would be really nice! I'd love to see sound_update_base and BKE_sound_update_scene gone. The biggest issue here is animation. Whenever some audio animation (volume, pitch, etc.) changes, all affected frames need updating. If that's possible with the dependency graph, that would be ideal! E.g., if an animation is changed by modifying the f-curve, that parameter needs to be updated for all frames that now have a different value.
Jun 7 2019
This should fix it, please check if it works for you too and feel free to reopen in case it doesn't.
May 30 2019
May 29 2019
What happens if you open a file that has AV-sync set? There you'll have the same behavior still. Or you set the synchronization to something else, which might not be what the user wants. I'm a bit hesitant in changing stuff without letting the user know. Especially, I would expect a file not to change if I only open and save it - independent of my user preference settings.
@William Reynish (billreynish) perfectly described it when he wrote
May 22 2019
Okay, will consider that in the future.
May 13 2019
May 10 2019
Blender 2.8 uses the latest version of audaspace where the aud API has changed considerably, please refer to the audaspace bindings API documentation.
Apr 28 2019
You're welcome. Thanks for reporting!
Apr 27 2019
I can't reproduce either, but that commit should fix it. Feel free to reopen if it doesn't.
Apr 14 2019
Nice find on where the problem was introduced! I'd be fine with the temporary fix. Are you sure that this doesn't prevent both calls of the two threads during rendering? One should still be done. I'm not sure what moving to the dependency graph will change here, does the dependency graph get updated from two threads as well? Or is it two different instances and thus as you said viewport and renderer each need their own sound_scene instance?
Apr 9 2019
I tried to reproduce the crash, but it also didn't happen on my linux. Given the stack traces though, it looks like the issue is BKE_sound_update_scene being called at the same time in different threads. As such a mutex in this function should solve the problem?
Apr 3 2019
Mar 10 2019
I fixed both issues.
Feb 23 2019
Feb 12 2019
@Hossein Shah (hk1ll3r), you're right the strip length stays the same, but that doesn't mean that the speed doesn't change. If you have a strip of full length (not cut on any side) and you change the pitch to 2, you'll end up with double pitch and double speed, but the strip will stay the same length, meaning that it's silent in the second half. We intentionally don't change the strip length when the pitch is changed, since this can cause many problems, especially when you animate the pitch. I hope this clarifies the issue. If not, please ask further questions on devtalk.blender.org as @Sergey Sharybin (sergey) suggested.
Feb 1 2019
Jan 22 2019
Just tried with setting it in C/CXX FLAGS but same result as with WITH_COMPILER_ASAN. Please let me know what you get with gcc9. If you still have it there, I fear you'll have to help me debugging this. ;)
Jan 21 2019
I tried reproducing - I enabled WITH_COMPILER_ASAN (and disabled cycles and libmv in order to get it compile on my machine) but I only get memory leaks when I run blender then, not the error you reported. Do you have any hints on how to reproduce it?
Jan 17 2019
Should be fixed in d3e856cd but I can't really test it. Please give it a try with a build bot build newer than this comment and check if it works there. If not, feel free to reopen this bug report!
Jan 12 2019
With your last two points you mean the playback device in the windows audio settings right? I guess you can recover if you go to the blender user settings and switch the audio device to None and back?
Dec 31 2018
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.
Dec 30 2018
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
Ok @Brecht Van Lommel (brecht). Since I'm not really a NLE guy, but rather a real-time guy, I'm also lacking some knowledge about that @Troy Sobotka (sobotka). If you have any resources on what a proper NLE would be (doesn't have to be audio specific), that would help. Also it might be interesting to talk to the actual Spring team in terms of what they would like or how it should work. Where/how should we continue this discussion?
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?
Dec 25 2018
Ok, let me add my 2 - or more like 1000 - cents here. TL;DR: I list 7 major problems with Blender in relation to audio.
Dec 24 2018
Sorry for the late reply, it's been a busy month, but now there are holidays :) The noise problem sounds weird, especially since you're the only windows user reporting it. Have you tried updating your drivers? Also have you tried SDL instead of OpenAL or None? Does saving the device settings work in the 2.80 beta?
Dec 5 2018
I guess this change needs more evaluation. If the change targets video encoding, I don't see on what basis the changes in audaspace are necessary? Does audio en-/decoding actually benefit from the changes? It also seems a bit random to have those changes for playing audio files and mixing down audio, but not for decoding videos (within movie clip editor or VSE)?
Oct 21 2018
Hey! Thanks for reporting the warnings! I'm not sure what to do about the macro redefinition. That's of course mainly a problem in the SDL source code - did you report it there or submit a fix? Your solution is certainly too broad of a workaround since it silences all those warnings even if there are legitimate ones in audaspace's code.
Sep 12 2018
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?
Aug 13 2018
Well, ideally you would use the offsets as they were used before. But if not, you don't have to convert before storing, since we're not forward compatible, but we have to be backward compatible, that's what do_versions() is for.
Aug 12 2018
I tried the patch. Animated strips work now, but I still have trouble with strips loaded from a file that was created with vanilla blender.
Aug 7 2018
Hey, sorry for the slow responses, I'm quite busy at work at the moment. Can you please update the patch? Currently it doesn't apply.
Aug 3 2018
Jul 11 2018
Jul 8 2018
Hey! Have you tried this with pitch animated sound? It still doesn't work. I've also found a few other bugs and might even find more if I keep digging.
Jul 7 2018
Jul 6 2018
Hey, thanks for the update! I tried it and it works really nice for strips with constant pitch. However it doesn't work for animated pitch at all. I think we should go a middle way and don't touch the strip length when the pitch is changed at all. Otherwise we get serious problems with animated pitch strips. The code for cutting and drawing would work fine, but we would have to remove the other changes I guess. Can you try strips with animated pitch? The goal is that the strip start and end don't change during playback.
Jun 26 2018
Ok, so the first problem is, that the display of the pitch scaled waveform is wrong in D3496 when the start is not 0. Changing the start on pitch change is also wrong, since the start of the playback of that strip doesn't depend on the pitch. So to keep the sound start at the same position when changing the pitch, you shouldn't do anything, because that's what happens right now.
Jun 24 2018
Jun 8 2018
I finally got around fixing everything in extern/audaspace in blender2.8 and committed this as dd2e1873446e2019a3020e9d62c6efc29b43d930. Everything above apparently has been fixed with ffmpeg_compat.h in master and blender2.8.