[gst-devel] [gstreamer] Problem with pulling data from a sink pad

[iain]

On Tue, 2003-12-23 at 17:52 +0100, Thomas Vander Stichele wrote:

> I think this is what you were trying to say with your sentence, but
> that's not what it said. 

Yeah, I suck.

> 

> Right.  So again.  What makes you think GStreamer is incapable of
> generating this peak file ? What is so exceptionally hard about this
> that you think this is the wrong thing to do with GStreamer ?

I didn't say GStreamer couldn't generate this peak file.
In fact, Marlin currently does use GStreamer to generate it. Well,It
uses GStreamer to stream the data into the SampleSink and the sample
sink generates it.
What I tried to say was that GStreamer is incapable of operating on it
in a non linear fashion without lots and lots of seeking around.

> 
> > To do it in GStreamer would be a seek to the position
> > Read frames_per_pixel frames and feed them though your peak level thing.
> 
> Nope.  That would be done for *calculating* the peak level once.

And then where do we stick the peaks?
In another file that we don't use GStreamer to look at?
Like the way I'm doing it now?
GStreamer loads the data, marlin tucks it all away for safe keeping.
Then, when we need to save or play it, Marlin feeds it all back into
GStreamer and we're all happy.

> Please don't be defensive about suggestions that there are operations
> done in your program that would be suitable for general plugification. 
> We'll meet somewhere halfway then.

I'm sorry,
but we've been over this many times before.
I can think of at least 3 occasions when we've had the exact same
conversation on IRC.

> > > > mmapping huge data to disk so that I can jump around it at will
> > > > without having to send a seek event, run the pipeline to get 2 frames of
> > > > data, send another seek event, run pipeline again...
> > > 
> > > Again.  What are you doing to jump around at will ?
> > 
> > Its a Non linear audio editor.
> > Why do you think I might be jumping around in a non-linear fashion?
> 
> There's no reason to be a smartass.

I'm sorry.
Thats why I expanded.
(but which you removed)

>   I'm asking the question to better
> gauge why you seem to think this is such deep magic that really only
> marlin can do this.  Of course you need to jump around at will.  But I
> am very skeptical that you would ever get 2 frames of data (given your
> implied definition of frame higher up in your mail which was meant to
> read as "the combination of one sample for each channel") and use only
> those two, because on 44100 Hz audio they would amount to less than one
> tenth of a millisecond.

Depends on the zoom setting.
If you zoom in so that its one pixel per frame then you could easily get
an expose event that requires you to draw only two frames.

> 
> So, really, you haven't answered the question at hand, only evaded it. 

Yes. I have.
The main reason that I need to jump around all the time is for redrawing
the waveform view.

> I don't see anything in marlin that would be hard to achieve through
> GStreamer plug-ins.  In fact, the only audio editor I've ever see
> something do that I would have a hard time seeing GStreamer do is sweep,
> with its scrubby feature.

Indeed, and a sample waveform view.
Which is kinda important in a sample editor.

> I'm not really sure why you're giving me the runaround on this matter. 
> It's ok to say "I don't feel like implementing stuff like plugins, thank
> you very much." 

I didn't say that, and when I get round to using LADSPA plugins I will
be doing them with GStreamer.
Currently effects are not done with GStreamer, but that is due to there
being more pressing issues to fix/rework on, rather than not wanting to
do it that way.

However, the fact still remains that GStreamer is good for streams of
data, not random access on that data.

iain
--