[gst-devel] a stupid question

[Thomas Vander Stichele]

Hey,

I'm picking up development again for an old gstreamer app I did two years 
ago that I need to use again pretty soon.

The concept was pretty simple: the app is supposed to record bits of audio 
coming in on the sound card, and each consecutive run of audio that 
crosses a given threshold for a set amount of time should be recorded to 
it's own file.

So the end result is a bunch of .wav files (or oggs, whatever) that each 
hold a piece of audio as it was read by someone.

The most important thing to get right in this app is the fact that the app 
should actually continuously pre-record to monitor the level, and when the 
threshold is crossed, it should also store the previous 0.5 secs of audio, 
so that the crossing of the threshold is stored as well, since that 
typically also contains audio to keep.

Now, back in the day I did this with very big hacks because gst wasn't 
up to snuff back then.

Basically, I had an osssrc ! cutter ! queue ! { passthrough ! disksink }
pipeline, where signals got connected to cutter to monitor the points
where to start and stop.

Then, a "start" signal would set the location on disksink to a new file,
and "stop" would set it to /dev/null.

The queue was used so that, when cutter decided that yes, this bit of 
audio is worth recording, it would be keeping a backlog of audio in it's 
queue so that when disksink got set to the right location, it would also 
store the small bit before the trigger point.

The main drawback was that back then I had to record to a raw audio format 
because there were no flush events and things like that to actually tell 
the encoder that it should close and terminate the file.

Of course, I would try to at least make it a better example of current 
GStreamer technology.

So here's where it could be improved upon, as well as my questions:

a) I would want to make the prerecord buffer a given size in audio 
duration.  I would think that it would be best to create an element
(say, "buffer" or "delay") that based on the caps/time properties would
be able to figure out how many buffers it should hold.
This element would not output anything until it's buffer is completely 
full, then output buffers from that internal buffer at the same speed 
they're coming in.  Would this work without threads if the element itself 
has the logic to output zero buffers in it's chain function ?

b) does sending a "flush" event on the queue's src pad currently work in 
that it flushes the whole queue so that it's empty, then makes the encoder 
(currently passthrough) also close the file properly, and then makes 
disksink flush it entirely ?
Can I, right after the flush, expect to change the pipeline and have the 
flush be completely finished ?

c) I would of course replace passthrough with an actual encoder (be it 
wavenc or vorbisenc or whatever) so that it is more sensible than it is 
now.

I'm especially interested in some way of dealing with the prerecord 
buffer, because that's the biggest problem right now.

Thanks,
Thomas


-- 

The Dave/Dina Project : future TV today ! - http://davedina.apestaart.org/
<-*- thomas (dot) apestaart (dot) org -*->
Gotta keep moving on
lover you hide from me every time
<-*- thomas  (at) apestaart (dot) org -*->
URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/