Re: [Libvisual-devel] VisAudio overhaul proposal.

[Vitaly V. B. <vit...@uk...>]

On Mon, 07 Mar 2005 20:50:23 +0100
Dennis Smit <sy...@yo...> wrote:

> The document:
> ====================================================================================
> 
> This document describes the initial VisAudio overhaul design.
> 
> Version 0.1
> 
> Dennis Smit <sy...@yo...>
> Libvisual project leader
> 
> _____________________________________________________________________________________
> 
> Goals:
> 	Ability to mix channels.
I think it would be nice to have an "audio filter" stack, tree or
whatever and some "control" api (on/off, value from a range)

> 	Audio energy registration, calculation (already done).
> 	normalized spectrum (logified).
> 	Internally, use floats to represent audio. (from 0.0 to 1.0 or -1.0 to
> 1.0 ?)
> 	Use floats to represent the spectrum (from 0.0 to 1.0)
> 	Have conversion code to go from short audio to float.
there's K7 (semi) optimized verions within scivi

> 	Basic conversion for the frequency (hz) of the input.
> 	BPM detection:
> 
> http://www.gamedev.net/reference/programming/features/beatdetection/page2.asp
> 
> 		Provide 6 vars to directly detect hits on the six bands.
> 
> Open questions:
> 	How do we want to do the number of samples ? (aka the length of the
> buffer)
> 	How to handle multiple channels, channel mixing, how to handle 5.1,
> 7.1, 9.1 etc ?
> 
> Internal audio representation:
> 	In floats.
> 	Fixed frequency ? (I personally prefer this)
I don't think it's good idea to use fixed single frequency...
Anyway, does it matter?

> 	How large do we want our buffers ?
Large buffer means high latency. Small buffer (upto 64 bytes) measns low
latency.

Personally I believe buffer should be variable in size. It will be
useful if we're going to use "audio filters".

What about audio frame timestamping?

How to guarantee (do our's best) to synchronize video with audio?
Hard video processing requires some time...

-- 
Vitaly
GPG Key ID: F95A23B9