Suggestions for audio source wanted

Carlos Rafael Giani dv at
Tue Feb 11 06:34:13 PST 2014


I have a library which produces audio data. I wish to wrap it in a 
source element.
There are some problems though:

* The source is not live like alsasrc for example - it can be made to 
wait until more samples can be consumed.
* The library for this source delivers samples by means of a callback. 
This callback must not block for long. If at time of calling no samples 
can be consumed, the callback can return 0, which will cause the pause 
mentioned above. The library simply invokes the callback again, about 
100ms later. This is akin to the polling strategy.
* The callback receives not only samples, but also format information 
(sample rate, sample format, number of channels, etc.). Which means 
these could change at any point in time.

I wonder what base class to use here.

GstAudioSrc does not work well, since it expects the subclass to be able 
to work in a pull-based manner (GstAudioSrc call the read() vfunc, and 
the subclass has to deliver the samples then). Here, it is the other way 
round. I could create some kind of FIFO between the callback and my 
read() function, but that does not solve the format change problem - I 
cannot call set_caps() inside read().

GstAudioBaseSrc is perhaps better suited, since it allows for a custom 
ringbuffer. But I cannot simply use commit(), since it may block. 
prepare_read() gives me information about how many samples I can write 
and where to write them to, but it must be this exact number of samples. 
What if for example prepare_read() informs me that it expects 5000 
samples, the library's callback provides me with 4000 samples, which I 
copy over, then in the next callback it informs me about a new format? 
Just call advance() (even though not all samples have been written; 
perhaps fill the rest with nullsamples) and then call set_caps()?

On top of that, GstAudioBaseSrc is derived from GstPushSrc, which, 
according to the documentation, is suited for sources which cannot seek 
or seek only very slowly. But the library can seek easily and quickly. 
Any recommendations? Simply overriding do_seek should suffice?


More information about the gstreamer-devel mailing list