Suggestions for audio source wanted
Carlos Rafael Giani
dv at pseudoterminal.org
Tue Feb 11 06:34:13 PST 2014
Hello,
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?
cheers
More information about the gstreamer-devel
mailing list