[gst-devel] (fwd) Re: gstreamer-devel digest, Vol 1 #1051 - 14 msgs

[Andy Wingo]

Another mail that didn't go through...

----- Forwarded message from Andy Wingo <wingo at pobox.com> -----

> From: Andy Wingo <wingo at pobox.com>
> Subject: Re: gstreamer-devel digest, Vol 1 #1051 - 14 msgs
> To: gstreamer-devel at lists.sourceforge.net
> Mail-Followup-To: gstreamer-devel at lists.sourceforge.net
> 
> > Subject: Re: [gst-devel] Midi and GStreamer]
> > From: Steve Baker <steve at stevebaker.org>
> > Date: 17 Jul 2003 19:26:25 +1200
> 
> > Just to clarify, this would work when your source is a midi file, so you
> > have access to all of you midi buffers ahead of time.
> 
> What a lame case! This *has* to work in realtime... the fact of the
> element being loop-based or not is irrelevant, IMO, as long as the
> duration of the MIDI buffer is (approximately -- doesn't MIDI have a
> bizarre 'sample rate'?) equal to the duration of audio buffers. No note,
> you get a filler event. That's not so efficient, though... why push data
> when there's no data? Oh well.
> 
> > In the case where you have a real-time input such as alsamidisrc, then
> > alsamidisrc will have to generate timestamped filler events so that
> > amSynth knows when it needs to spit out an audio buffer. In this case
> > latency would be minimised by matching the period of fill events with
> > the the size of your audio buffers.
> 
> I'm replying to this just to say this is the purpose of buffer-frames in
> the new float caps, essentially. Just to be clear ;)
> 
> regards,
> 
> wingo.
> 
> 

----- End forwarded message -----