[vlc-devel] [PATCH] Vovoid VSXu audio visualization integration

[Rémi Denis-Courmont]

	Hello,

Le lundi 12 mars 2012 23:45:16 Jonatan Wallmander, vous avez écrit :
> To accomplish this, I wrote a cyclic buffer class for interim storage of
> audio fragments as I found out that the Project M implementation (which
> I forked) receives audio  0.3-0.4 seconds out of sync (ahead of time;
> may vary for you), using PTS values sent via block_t.i_pts.
> Synchronization really makes or breaks a music visual. If you want to
> test audio sync with visuals, use this file:

I'm not sure what you mean. The PTS values should be correct. However, the 
audio output actual play time estimate is allowed to drift -40/+60 ms from the 
PTS. If you experience more desync, there may be a bug somewhere.

> https://github.com/vovoid/vsxu/blob/master/tests/audio/latency_test.mp3
> (series of 880Hz beeps)
> 
> If there's a better (VLC) way to do this, I should do/use that instead.

I'm not sure. <vlc_block_helper.h> can probably do that.

> The code is also doing some tricks to keep VSXu getting at least 60
> Hz/FPS (512 sample blocks) of audio data so that the visualization is as
> exact and dynamic as possible (the concept is: vsxu must have new audio
> data every frame, VLC doesn't call its audio filter callback that often).

VLC calls the audio filter whenever it has new data, and up to 2 seconds ahead 
of playback time. The block size is usually set by the codec, unless it is 
modified by previous filters in the chain. VLC does not (anymore) packetize 
decoded audio samples to a fixed size: it only increased latency, with no 
practical benefits. Anyway, the audio buffer should be much longer than 1/60Hz 
so this should not be a problem for you.

Note that there is no warranty that the sample rate is a multiple of 60Hz. 
Most common rates are including 48kHz and 44,1kHz. But notably 8kHz, 16kHz and 
32kHz are not.

-- 
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis