[gst-devel] Can a controller use a different clock?

[Steve Fink]

On 6/5/07, Stefan Kost <ensonic at hora-obscura.de> wrote:
> hi,
>
> Steve Fink wrote:
> <snip>
> > I want dynamic volume control with a stream that I am seeking around
> > within. Specifically, I want two very different types: (1) I want to
> > overlay a volume "track" on top of a stream where the volume at any
> > point is tied to the offset within that stream, and (2) I want a
> > volume adjustment that happens relative to playback time. #1 is used
> > when using a single source sound clip and making several variations,
> > where each variation has its own settings for what part of the clip
> > should be loud and what part should be soft. These variants will be
> > played back with occasional nonlinearities where I seek to different
> > points within the clip, and the same part of the clip for a given
> > variant should always have the same volume. #2 is used for fading out
> > the playback, probably because you're switching to something else. (It
> > may not be a global fade across all clips, though; there may be other
> > streams getting mixed in on their own timelines.)
>
> You schedule parameter changes as soon as you know when they should happen. If
> you want to fade out the volume as a result of a button click the I would query
> the position of the stream in the button-pressed callback and schedule two
> parameter changes [position,1.0],[position+(3*GST_SECOND),0.0]. Maybe adding a
> little to the first control-change position. Also set the interpolation mode to
> linear.

This would not work for the usage I was describing, although it may be
that the usage I was describing is just not the way things are done in
gstreamer.

I have an incoming stream, which I am not really using as a stream. I
play the first 1200ms, then seek to 03:00, then play another 1000ms,
then seek back to 00:05, play another bit, etc. I'm essentially using
a single stream as a randomly accessed series of clips, and seeking
within stream time to do the accesses. I'm making a distinction
between stream time and playback time because I'm seeking the stream
time all over.

Your solution only works within stream time. If I happened to do a
seek at 1.5*GST_SECOND, then my fadeout would be "cancelled".

Is the problem my usage of seeking? Should I have a nonlinear-audio
plugin that accepts my "seek" events (using a custom event rather than
the seek event) and produces a consistent, monotonically increasing
stream time like normal gstreamer streams? Can I partition the "time
domain" of portions of my pipeline?