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

[Lars Krueger]

Hi.

First, a disclaimer: I don't know the details of how the animation system is implemented. I do, however, work extensivly with multithreaded asynchronous data processing.

My suggestion is this: 
- The animation system puts the audio-related info in a queue. A length of 3 images should be sufficient. Make it longer, if you have the memory and more cores. Make sure you have critical section/mutexes around the access code.
- The audio system renders a frame and puts it in the same queue as the animation data.
- The audio thread waits for the queue to be filled enough to its work. Whether you that by polling or a signal is up to you. It fetches the relevant animation data (Mutexes again!) and generates as much audio from it as it can. This is written to proper slot in the queue (e.g. one image before the animation data).
- An additional thread (or a part of the animation thread) checks if audio data is available in the first entry of the queue, and sends it and the image to file.

>From you description I'd guess, you need a mutex, a signal and a queue and the code can remain almost unchanged.

General advice, try to keep the number of mutexes low unless you a very compelling reason to do a more fine-grained locking. A few percent performance improvement is not a compelling reason to juggle 10 mutexes.

My 2 cents

-------- Original-Nachricht --------
> Datum: Sun, 17 Jul 2011 08:31:43 +0200
> Von: neXyon <nexyon at gmail.com>
> An: bf-committers at blender.org
> Betreff: [Bf-committers] Help needed! Animation problems for 3D Audio GSoC

> 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

-- 
Dr. Lars Krueger


Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de