Audio via shmem and preserve clock for adder plugin?

[Simon Brandner]

Hello together,

I would like to realize interprocess audio streaming with gstreamer -
as lightweight as possible, so things like UDP are preferred to be
avoided.
Therefore I am using the shmem plugin with  GStreamer version 0.10.36
under Ubuntu 12.04. (in Ubuntu 12.10 the shmem plugin seems to have
been patched into "good" - I have not tried with that yet).

As audio-source I use:
gst-launch-0.10 filesrc location=../Music/title.mp3  !  mad !
audioconvert ! "audio/x-raw-int,endianness=1234,signed=(boolean)true,width=(int)16,depth=(int)16,rate=(int)44100,channels=(int)2"
 ! shmsink socket-path=/tmp/shmsink shm-size=10000000
wait-for-connection=false preroll-queue-len=5

The playing part is:
gst-launch-0.10 shmsrc socket-path=/tmp/shmsink !
"audio/x-raw-int,endianness=1234,signed=(boolean)true,width=(int)16,depth=(int)16,rate=(int)44100,channels=(int)2"
! audioconvert ! alsasink

This constellation just works fine.

For full functionality I would also need an adder to combine multiple
audio sources in a pipeline, so for one source it is looking like:
gst-launch-0.10 shmsrc socket-path=/tmp/shmsink !
"audio/x-raw-int,endianness=1234,signed=(boolean)true,width=(int)16,depth=(int)16,rate=(int)44100,channels=(int)2"
! audioconvert ! adder !  alsasink

// Unfortunately then, I get a crackling in the sound and several
error messages:
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...

** (gst-launch-0.10:32308): CRITICAL **: gst_audio_buffer_clip:
assertion `segment->format == GST_FORMAT_TIME || segment->format ==
GST_FORMAT_DEFAULT' failed
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstAudioSinkClock

** (gst-launch-0.10:32308): CRITICAL **: gst_audio_buffer_clip:
assertion `segment->format == GST_FORMAT_TIME || segment->format ==
GST_FORMAT_DEFAULT' failed

** (gst-launch-0.10:32308): CRITICAL **: gst_audio_buffer_clip:
assertion `segment->format == GST_FORMAT_TIME || segment->format ==
GST_FORMAT_DEFAULT' failed //This message comes cyclically, just as
the crackling noise.


I would assume that through the shmem, a clock/timestamp information
is lost, because a single pipeline without a shmem in beetween works
fine with the adder. The message "New clock: GstAudioSinkClock" also
points to this, and that the adder requires one. How could I tunnel
the timestamp through the shmem, or create a valid new one? Could a
small buffer eliminate the problem?

Any way to solve the problem differently would also be welcome.


Thank you.
Regards,

Simon



PS:
Not very relevant for now, but a short try with GStreamer 1.0.2 even
failed without shmem and adder:
gst-launch-1.0 filesrc location=../Music/title.mp3  !  mad !
audioconvert ! "audio/x-raw,endianness=1234,signed=(boolean)true,width=(int)16,depth=(int)16,rate=(int)44100,channels=(int)2"
 ! alsasink
"ERROR: from element /GstPipeline:pipeline0/GstFileSrc:filesrc0:
Internal data flow error.
Additional debug info:
gstbasesrc.c(2791): gst_base_src_loop ():
/GstPipeline:pipeline0/GstFileSrc:filesrc0:
streaming task paused, reason not-negotiated (-4)"
My hope was, it would be more simple there..