[gst-devel] Re: gstreamer-devel digest, Vol 1 #1111 - 4 msgs

[Andy Wingo]

Hi Thomas,

> The problem was, since it was analyzing audio before it went to the
> sink, the VU meter displaying the audio level was preceding the actual
> output. It would be nice to find some way to fix this.

For the record this is a common audio problem. The way this is solved in
jack is with the following API; their concept of ports is about the same
as our pads. From jack.h:

/**
 * Returns the time (in frames) between data being
 * available or delivered at/to a port, and the time at
 * which it arrived at or is delivered to the "other side"
 * of the port.  E.g. for a physical audio output port, this
 * is the time between writing to the port and when the
 * signal will leave the connector.  For a physical audio
 * input port, this is the time between the sound arriving
 * at the connector and the corresponding frames being
 * readable from the port.
 */
jack_nframes_t jack_port_get_latency (jack_port_t *port);
 
/**
 * The maximum of the sum of the latencies in every
 * connection path that can be drawn between the port and other
 * ports with the JackPortIsTerminal flag set.
 */
jack_nframes_t jack_port_get_total_latency (jack_client_t *, jack_port_t
*port);
 
/**
 * The port latency is zero by default. Clients that control
 * physical hardware with non-zero latency should call this
 * to set the latency to its correct value. Note that the value
 * should include any systemic latency present "outside" the
 * physical hardware controlled by the client. For example,
 * for a client controlling a digital audio interface connected
 * to an external digital converter, the latency setting should
 * include both buffering by the audio interface *and* the converter.
 */
void jack_port_set_latency (jack_port_t *, jack_nframes_t);

I tend to think this a much more gstreamer-friendly solution. I don't
think level calculation belongs in sink elements; it would be much more
useful as a separate element.

Putting the level calculations in the audio sinks stil has the problem
that the audio hardware has a certain latency as well -- the signal
would still need to be delayed for it to be truly useful.

Anyway, those are my thoughts. As I look in gstquery.c, I see we already
have a latency query-type; why not use that?

regards,

wingo.