[Bf-committers] Help needed! Animation problems for 3D Audio GSoC

[Martin Poirier]

Hi,

I'd like to ask people with good knowledge of Blender's animation and animation related structures to please consider this problem, this is rather important for neXyon's GSOC project.

Thanks,
Martin

--- On Sun, 7/17/11, neXyon <nexyon at gmail.com> wrote:

> From: neXyon <nexyon at gmail.com>
> Subject: [Bf-committers] Help needed! Animation problems for 3D Audio GSoC
> To: bf-committers at blender.org
> Received: Sunday, July 17, 2011, 2:31 AM
> Hi guys!
> 
> There's a serious problem with the way how animation works
> in regard to 
> audio. The main problem is, that the animation system
> pushes the output, 
> so it sets the data, renders a frame, advances to next
> frame (setting 
> the data there) and renders again and so on, this works
> pretty good for 
> video. But it doesn't work with audio, especially as audio
> has a very 
> high temporal resolution (48000 eg. samples per second)
> compared to 
> video (eg 25 frames per second) and moreover for audio the
> output device 
> pulls the data, instead of the animation system pushing it,
> so the other 
> way round.
> 
> I talked to Martin (Poirier) and Joshua (Leung) and even we
> three 
> together cannot think up a nice solution for the problem,
> maybe some 
> genious mind here on the list who is more into the
> animation code than I 
> am has a really nice idea.
> 
> Here are specific problems in detail:
> 
> * Subsample Accuracy: To avoid stair steps as we currently
> have in 
> volume animation.
> * Multi Threading: Audio runs in a separate thread.
> * Speed: The access mechanism has to be realtime capable!
> * Asynchronous access: Audio playback is ahead of video
> playback 
> normally (buffering the samples, feeding them to the output
> device).
> 
> The first point can be solved easily with a proper
> interpolation if you 
> have two nearby samples, one in the past, one in the
> future, so this 
> basically requires the animation data to be cached/buffered
> somehow or 
> at least asynchronous accessible. As the cached data also
> solves points 
> 3 and 4 it's pretty obvious that we need the data cached,
> we had that 
> conclusion already.
> 
> Questionable is now how to get the cache? One obvious
> solution is to 
> require the user to "bake" it, but this heavily impacts how
> easy the 
> system can be used and as we also already concluded this is
> a really 
> ugly solution. Better is the automatic caching which leads
> us to the 
> problem point 2 multi threading. I don't know if it's
> possible to cache 
> in the main thread? I bet not. And as long as blenders
> (animation) data 
> isn't accessible multithreaded we still have no solution
> for the problem.
> 
> So now your help is needed. Any ideas? If not I'll have to
> do the baking 
> solution to finish the project.
> 
> Regards
> 
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>