Audio base classes

From Buzztard

We should focus on a GstAudioGenerator and GstAudioFilter baseclass to replace the need of a song tempo interface and have a better means for mute and bypass behaviour. This would also be useful for the existing elememnts in audiofx plugin which are subclassing GstBaseTransform or GstAudioFilter right now. Finally it should be used in Lv2 GSoC 2009 project.

Some details about the features:

• tempo: many audiofx become more useful if the can be sync with the musical timing, e.g. an echo that runs in sync with the bpm
• mute/bypass: every audio mixer has mute/solo/bypass in the channel strips. Mute silences the output. Solo mutes all other strips (and should be handled by the application). Bypass is actually a special setting of Dry/Wet function (namely Dry) - this is simmilar to Mute being a special state of a volume control (namely volume=0). Most effects have a Dry/Wet control that can mixes the dry input signal with the wet effect signal. This allows to have e.g. a bit less of the effect. Setting bypass on and off, allows to do a before/after comparission.

Base, Audio, Video

If there are similar usecases for video, we should consider extending GstBaseTransform and GstBaseSrc, otherwise GstAudioFilter and GstAudioSrc for audio and GstVideoFilter and (no yet existent) GstVideoSrc.

GstAudioFilter

GStreamer already has a base class .c, .h for this. It would need some changes:

• add tempo iface properties
• add bypass/mute properties
  • bypass: create output without effect
  • mute: create silent gap buffers
• remove limmitation input-format=output-format
  • GstAudioPanorama is currently not a subclass of GstAudioFilter for that reason. A Panorama element can be set to bypass, for mono input it would become a normal mono 2 stereo conversion. Because of that bypass needs to be actively supported by the plugins (do we need gst_audio_filter_can_bypass()).

Currently there is also spectrum and bpmdetect subclassing GstAudioFilter, but its actually not a filter as it never modifies the data. Should we have GstAudioAnalyzer and GstAudioProcessor and deprecate GstAudioFilter. Or should we just introduce a new GstAudioTransform.

Then there is Ladspa having GstSignalProcessor class .c,.h. I basically implements a mechanism to sync buffers (see gst_signal_processor_process(). In GStreamer dataflow is triggering processing. In e.g. Ladspa and also LV2 one calls process and this needs to have data ready for each input. As data buffers are always mono in those two, one needs to sync e.g. two mono buffers for stereo effects.

GstAudioGenerator

Planned features:

• add tempo iface properties
• add mute properties
  • mute: create silent gap buffers

General points

• when introducing new base classes we should also add a GstAudioFormat struct... abusing the GstRingBufferFormat in GstAudioFilter is a bit ugly :) (note that e.g. video already has GstVideoFormat)
• the audio processing base classes should split the buffers into smaller chunks for GstController (they can make use of the tempo iface properties to calculate the chunksize)
• The buffer management scheme of GstSiganlProcessor in ladspa would be interesting as a helper object like GstAdapter, GstCollectPads - its basically a GstCollectPads which also manages the src pads and has some hardcoded values regarding data format.