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

[Stefan Kost]

Hi,
Steve Fink wrote:
> 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".
>
You want the fade to continue, despite you are seeking? Then you would need a
element that re-stamps buffers and maybe put the audio decoding element into a
bin and seek on that.

> 
> 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?
> 
I still have not a clear picture what you app should do. The concept of the
controller is to bind parameter changes to timestamps.  Maybe its easier for you
to have a idle-handler that does that changes based on playing time.

Stefan