Suggestions for audio source wanted
ensonic at hora-obscura.de
Wed Feb 12 10:05:45 PST 2014
On 02/11/2014 03:34 PM, Carlos Rafael Giani wrote:
> 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.
Is the library calculating the audio? I am using GstBaseSrc for my audio
synths in buzztrax. I have a GstAudioSynth baseclass there:
> 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
> 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?
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
More information about the gstreamer-devel