[gst-devel] OpenAL sink

[Babineau, Denis]

Hi, I'm trying to write an audio sink for OpenAL (if such a thing
already exists, please point me to it, because I haven't found it! J ).
I'm subclassing GstAudioSink and am a bit confused regarding some of the
values passed in the prepare() function (GstRingBufferSpec struct) and
would appreciate a bit of direction. From the docs:

 

  guint64  latency_time;        /* the required/actual latency time,
this is the

                                * actual the size of one segment and the

                                * minimum possible latency we can
achieve. */

  guint64  buffer_time;         /* the required/actual time of the
buffer, this is

                                * the total size of the buffer and
maximum

                                * latency we can compensate for. */

  gint     segsize;             /* size of one buffer segment in bytes,
this value

                                * should be chosen to match latency_time
as

                                * well as possible. */

  gint     segtotal;            /* total number of segments, this value
is the

                                * number of segments of @segsize and
should be

                                * chosen so that it matches buffer_time
as

                                * close as possible. */

 

All 4 values are under [in/out] so I don't know if it's inputting
recommended values with the option of tweaking them? Regarding
latency_time/buffer_time, I'm leaving them as defaults (they can be
modified thru the properties) and by default I get values of 10,000/0
respectively with my test. Segsize/segtotal I take as "buffer size" and
"number of buffers", with OpenAL I have to pre-allocate buffers and
while running I write to the buffer and queue them (and unqueue
processed buffers). And so in my test I get 882 segsize and 20 segtotal
so I pre-allocate 20 OpenAL buffers and fill/queue them during the
write() call but what appears to be happening is that all the buffers
gets full before even one buffer gets processed by OpenAL so I end up
overrunning my buffers. Should I be stalling the write() call? Also, do
those values make sense? When I normally stream a sound in OpenAL (not
synced to video) I would allocate fairly large buffers, but not so many
(2-3 buffers large enough to keep about 2-3 seconds buffered).  But here
from what I understand it's suggesting I allocate buffers of only a few
samples each (i.e. 882 / 4 = 220 samples).

 

At this point I'm not too worried about latency/delays; I'm just trying
to get something playing sound so that I get a better feel as to how
this interface works.

 

Any input appreciated!

 

Thanks

Denis

CONFIDENTIALITY NOTICE: The contents of this email are confidential
and for the exclusive use of the intended recipient. If you receive this
email in error, please delete it from your system immediately and 
notify us either by email, telephone or fax. You should not copy,
forward, or otherwise disclose the content of the email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20100201/e6484bb5/attachment.htm>