[Bug 705870] audiobasesink: add callback for custom logic based on the sink's average skew value

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=705870
  GStreamer | gst-plugins-base | git

--- Comment #3 from Carlos Rafael Giani <dv at pseudoterminal.org> 2013-08-13 23:31:30 UTC ---
(In reply to comment #1)
> Review of attachment 251421 [details]:
> 
> ::: gst-libs/gst/audio/gstaudiobasesink.h
> @@ +104,2 @@
>  /**
> + * GstAudioRingBufferCallback:
> 
> Shouldn't this instead be a vfunc inside the class? Isn't it class specific?
> Also shouldn't it somehow circumvent the existing skew logic?

I do not see this as class specific. This kind of logic is most likely written
by application developers, _not_ plugin developers. Plus, putting this in a
class would imply that the interface for adjusting the audio hardware is
tightly coupled to the interface used for audio output, which is rarely the
case. Consider what can be inside the callback. That would typically be either
some kind of PLL adjustment (which implies customized audio hardware and a
nonstandard extra interface for the adjusting), or an asynchronous resampler
(in software or in hardware). If this were a vfunc, you'd have to extend all
sinks you want to support: alsa, pulse, waveform, jack, ... In my opinion, this
is related to the case of OOP composition over inheritance.

I expect this feature to be used mostly by embedded developers who have
customized hardware and want to take care that the drift is precisely
controlled. A common way to do that is to use a standard interface like ALSA
for the common audio I/O and some additional interface for the drift control. A
completely new audio interface is much less common (it is cheaper to get some
audio DAC with existing drivers and customize these a bit).

This callback complements the skew logic, it does not replace or circumvent it.
Its effects can indirectly have an impact on the skew logic, of course; if I
speed up the hardware based on the average skew, then the subsequent skew
values will be affected. But the intent is to be able to do more than just skew
the playout pointer; skewing should be an operation for large drifts, while
something else should be used for fine-grained adjustments. With the callback,
I can combine both: set drift-tolerance to something large, and the custom,
platform/hardware-specific code inside the callback can do the fine-grained
work.

I will fix the other points tomorrow, thanks for highlighting the problems.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.