Question on audio buffer in XMMS/Audacious
Added by Zhe Chen almost 11 years ago
Hello everyone,
I have read a tutorial from this link:
http://www.nobugs.org/developer/xmms/xmms-nobugs.html
There are two key functions (defined in _Visplugin structure, they are renamed in later version ):
1. void nobugs_render_freq(gint16 freq_data2[256]) // 2 channel * 256 frequencies
2. render_pcm() // I find that this function has a buffer sized [2][512] // 2 channel * 512 samples
I guess these functions always buffer the last 256 or 512 samples from each (decoded and "rendered" )channel for plugins. Is it right?
I can not find details of these buffers in the source code of XMMS and Audacious. I don't know whether their length varies at different sampling rate, and how they are passed from the previous core audio processing stages. Would you please help me trace their path?
Thanks
Replies (2)
RE: Question on audio buffer in XMMS/Audacious - Added by John Lindgren almost 11 years ago
These are the current options for a visualization plugin in Audacious (copied from plugin.h):
/* 512 frames of a single-channel PCM signal */ void (* render_mono_pcm) (const float * pcm); /* 512 frames of an interleaved multi-channel PCM signal */ void (* render_multi_pcm) (const float * pcm, int channels); /* intensity of frequencies 1/512, 2/512, ..., 256/512 of sample rate */ void (* render_freq) (const float * freq);
render_mode_pcm() and render_multi_pcm() always get 512 samples (per channel), no matter the sampling rate. In the various stages of audio processing, visualization plugins currently come after decoding, Replay Gain, and effect plugins; but before the equalizer, software volume adjustment, and the last format conversion. If you want to know more about a specific stage, I can point you to the relevant location in the source code.
RE: Question on audio buffer in XMMS/Audacious - Added by John Lindgren almost 11 years ago
There are several visualization plugins in the audacious-plugins package. You might want to look at how they do things. Also keep in mind that any tutorial for XMMS is going to be of questionable relevance for Audacious since it has been over a decade since the code was forked. In particular, ignore this section:
If we can’t do heavy processing in render_freq(), we’re going to have to spawn a second thread and let it process the data. Our worker thread will execute in parallel with the main xmms thread, and we’ll get uninterrupted audio.
Keep your code simple and do all your processing within the render_* callbacks. In Audacious you don't need to worry about interrupting the audio stream.