- User Since
- Feb 4 2009, 8:52 AM (424 w, 4 d)
Wed, Mar 8
Mon, Mar 6
Well yeah, it's not so easy... I actually had to figure out again, why it's so problematic in detail, when I was writing this, that's a reason why it took so long...
Sun, Mar 5
Fri, Mar 3
Feb 10 2017
Hmm, sounds like a problem of OpenAL/pulseaudio, so I guess there's nothing I can do here. It works fine for me, but then again I don't have pulseaudio even installed. ;-)
Feb 9 2017
As there hasn't been a response for a week, I'm closing this. Feel free to reopen if the bug in Blender still persists.
Jan 6 2017
Jan 4 2017
Hi, can you try if D2447 fixes your problem as well? I'd prefer if the code of changing the specs is run as seldomly as possible/necessary. This is to avoid for example resetting the resamplers everytime you pause/play.
Dec 27 2016
Nice report @Tobiasz Karoń (unfa). I see two things here: the first thing is the difference of one off, which I could reproduce and is a bug of ardour and the other one I couldn't reproduce and is cause by blender.
Fixing this with a workaround by disabling JACK Transport functionality during rendering. Thanks @Bastien Montagne (mont29) for the help on IRC. A proper solution would be blender supporting animation playback during rendering, but I guess we are far away from that. ;-)
Dec 26 2016
Is this still a problem with 2.78a?
Is this still a problem with 2.78a?
So yeah this is happening. I managed to fix the bug by preventing the sound system to change the current frame (cfra) and start/stop playback while rendering in an ugly way (if WM_jobs_test(wm, scene, WM_JOB_TYPE_RENDER)). The problem atm. is that I can only do these tests in the user interface, but not in sound.c of blenkernel, so if playback is started via jack transport while rendering, sound starts playing in blender and you don't have a way to stop it at the moment, ideally it would be completely ignored during rendering. To fix this I have to find a way in sound.c to find out whether blender is rendering right now (having access to a Main*). Can you help me with that @Bastien Montagne (mont29)?
Nov 28 2016
Nov 9 2016
Nov 7 2016
Oct 24 2016
Yeah, I could set the starting value to 0, then every strip gets an automatic fadein at the beginning, but not when seeking (this includes Blender jumping back to the beginning of the animation when it reaches the end), so in any case the solution won't be perfect. :-/ A nice solution that I have in mind requires quite big changes in the library, that are planned for audaspace 2, that I haven't started coding yet.
Oct 22 2016
Well, how do you expect a change made at 3 PM to be included in a build from 4 AM? You'll have to wait for a new build!
@Tobiasz Karoń (unfa): can you try with this fix if it works for you? For me it works fine now, but maybe I didn't catch all cases where it crashes. If you don't build blender yourself, you can try a version from a build bot that's new and includes that revision.
If you make changes like this, please test them Bastien, you completely broke JACK, because JACK != Jack...
@Olly Funkster (Funkster): you're right, it's not completely gone. I implemented a fix for this which is a bit simpler and less intrusive in the library. Thanks for your help again!
Oct 21 2016
Thanks @Sergey Sharybin (sergey), I was already on it, so here are the results of my investigation:
Oct 19 2016
I'm currently a bit unsure if this is a limitation or an actual bug @Aaron Carlisle (Blendify). Reading so far, the solution with the interpolation for audio buffer chunks sounds like what should be implemented right now, but I could be wrong and need to check the code better. Afair there is even spline interpolation in the code. @Olly Funkster (Funkster) can you just post the diff of what you did and then we can work together on a proper solution? Thanks!
Oct 17 2016
UI wise I don't like choosing output presets changing these settings. The worst case of a UI would be where you change some setting and that changes something at a completely different location.
Sep 19 2016
Hmm yeah, we could change that. At the moment for playback inside Blender the user preference settings are used. Ideally people would get the preview of how it would sound after export, so we could use those settings. The problem is that in the end you're always forced to use the user preference settings as maximum as you can't play 5.1 sound through stereo output or 96 kHz through 48 kHz output obviously...
By default Blender uses OpenAL for playback, more specifically on Linux typically OpenAL soft is used. This can be configured as shown here: https://github.com/kcat/openal-soft/blob/master/alsoftrc.sample
Sep 3 2016
The reason behind this is, that the Audio settings (first screenshot) are independent of the encoding and important for the playback not only the encoding of a scene. They are mostly unrelated to ffmpeg settings, unlike the Encoding settings (second screenshot). Asking to put for example volume under Encoding is as if you would do the color balance of your images in the export settings. If we do something it would make sense to remove the extra volume setting there, leaving the only two settings that are encoding related: codec and bitrate.
Aug 29 2016
No, thank you for the patch! I didn't have to do anything ;-)
Jul 25 2016
On second investigation, I tried playing back the file with vlc and mplayer, both of them also have troubles at the beginning, so I think it's the file that is broken here, not the software.
Very interesting behavior. The silent part in the beginning of the audio is always skipped when playback is started (that means, actually starting playback, scrubbing or moving the cursor during playback) at that position. If playback starts somewhere in the non-silent part it works. The problem is caused by FFMPEG not seeking properly in the silent part, which unfortunately means, that we can't fix the bug, it has to be fixed in ffmpeg.
Jul 23 2016
Jun 28 2016
Hmm, it works fine for me, but I'm on linux, not on a mac. Could someone with a mac try to reproduce this?
May 24 2016
Please do a little more research before opening bug reports like this.
May 1 2016
Yep, this is a duplicate of T47699. As written in that bug report, the issue has been fixed upstream and Arch is apparently waiting for a release of upstream code. @Chris Foster (kiravakaan): unfortunately I can't accept your patch. When I investigated T47699 I had the same fix/hack, but I don't think it's smart to ignore the library reporting the file to be non-seekable if we want to be future proof.
Mar 26 2016
And finally, I just found the bug report that has been submitted to libsndfile already and is fixed, so it will work again after the next release: https://github.com/erikd/libsndfile/issues/124
I just found another check:
I'm running Arch linux and can confirm the issue. It's with libsndfile actually which reports flac files as not seekable when opening the file . Interestingly the seeking works nevertheless, but Blender does not do it when libsndfile reported that seeking doesn't work (for obvious reasons).
Mar 23 2016
The default has been changed in the code, that means a fresh blender or factory reset of the user settings will have 48 kHz as sampling rate.
Mar 22 2016
Yep, it is known. Also audio animation does not work at all for negative frame numbers as the cache doesn't support negative positions. If you use audio, do not use negative frame positions.
Mar 20 2016
This is probably not a bug. The speaker positions are not exactly at +/-2 as this would be back center - the panning value basically gives you the direction where the sound is coming from if you multiply it by 90 °. For example: 2 * 90 ° = 180 ° = exactly from the back.
Mar 18 2016
Just based on the comments it seems like the bug is caused by the missing frames in the source file. During playback blender respects the PTS (presentation timestamps) in the video and is fine, but during rendering the output, blender just uses the next frame every time, ignoring the PTS and thus time compressing the video. To test this, you could simply use ffmpeg to reencode the video, to fix the missing frame issue and then try again to use this video in blender.
Mar 12 2016
It's definitely not an audio bug. I think it's a video bug, blender plays correctly, but the rendered output is wrong.
I'm sorry, but you are wrong. Audio works fine in the original file and in the rendered output, the problematic part is the video which in the rendered result seems to run at a faster speed than the original. I tried this by playing back both videos at the same time.
Feb 28 2016
The cache is already how it would be implemented in the code, it's not something you can just do in Blender.
Feb 27 2016
This can not be as easily solved as you think it can be. The problem is that the pitch can be animated. A proper solution would be to somehow cache the start position in the sound for every frame. This is not done anywhere at the moment.
Jan 9 2016
Hmm, I'd like to help, but I can't reproduce the problem here and I don't have a Mac...
I committed an updated version of the patch as rB85d675963665: Audaspace: Sequencer sound bugfix and mono UI.
Ok, I tried again and figured, that the sound I tried with was a stereo sound. As the tooltip correctly states, panning only works with mono sources.
Jan 8 2016
I just tried, panning is not working. Will look into it as soon as I have time.
That's not a bug, have you tried +/-1 instead of +/-2? -1 is left and +1 is right, +/-2 is centered in the back which in stereo is the same as 0 panning, you will only notice the difference with more speakers.
Dec 27 2015
Just to clarify: this message is printed by OpenAL soft and cannot be suppressed in the blender code. I think switching to 48 kHz as a default is the best solution and that's what the committed fix does. I was worried if we get the opposite error message now, with hardware only supporting 44.1 and not 48 kHz, but according to  this does not seem to be the case. In any case 48 kHz seems to be the superior default when I looked up the alternatives .
Dec 25 2015
Even without testing I'm quite sure that this still happens, as nobody implemented a feature to fix this.
Dec 2 2015
Nov 30 2015
Well it's the build bot, which is basically used for testing, official builds are built manually if I'm not completely wrong, but yeah from now on the future official will be built with libsndfile enabled.
@Sergey Sharybin (sergey) just built these with libsndfile:
I just talked to @Sergey Sharybin (sergey) on IRC and he told me that the official builds are built with libsndfile disabled, so it's ffmpeg causing the issue after all. Will try later to build blender with disabled libsndfile and check if I can reproduce the bug.
Nov 28 2015
Very interesting, just like the other bug, I can reproduce the problem with the official build but neither with my own nor my distro's (Arch) build. A flac file export is using libsndfile and not ffmpeg. Are you using the official build or the blender version coming with Debian? Either way, can you check if the bug appears with the respective other versions as well?
Nov 10 2015
Nah, 1.6.0 is old, 1.16.0 is the current version.
Nov 3 2015
Yes, during playback the aliasing (not antialiasing...) will be there. It will be removed when rendering output video, yes. And as I wrote in the commit log, playback uses low quality resampling because of performance.
Yep, those additional peaks are the antialiasing I talked about. With the current Blender version you will have to downmix the audio and multiplex that to your video by hand.
Btw: Audio mixdown does high quality, but normal animation rendering does not, that's indeed a bug, will fix in a second!
I know you don't want to hear it, but this is not a bug of Blender. xD
Oct 26 2015
I could reproduce the bug with jack and old (default) audaspace. Are you using Jack on purpose?