RE: alsasink underrun recovery issue in a synchronized streaming

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

RE: alsasink underrun recovery issue in a synchronized streaming

Charlie Laub
-----Original Message-----
From: gstreamer-devel [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Saturday, February 24, 2018 4:00 AM
To: [hidden email]
Subject: gstreamer-devel Digest, Vol 85, Issue 56

------------------------------

Message: 4
Date: Sat, 24 Feb 2018 00:55:38 -0700 (MST)
From: "danny.smith" <[hidden email]>
To: [hidden email]
Subject: alsasink underrun recovery issue in a synchronized streaming
        usecase
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=UTF-8

Hi all,

I am using scenario where we stream synchronized audio from one sender to multiple receivers using the approach outlined in the 2015 Gstreamer conference in Dublin by Sebastian Dröge (Synchronised multi-room media playback and distributed live media processing and mixing).

I have set up my latencies towards a more "low-latency" usecase and it works fine.

When I stress my receivers by doing other stuff on the same platform I get alsasink underruns which are expected due to small buffers and period times but not a problem for my usecase. However, quite often the pipeline does not recover correctly from these underruns. Audio can disappear completely, sometimes it comes back a while later. It can also become distorted.

We are using gstreamer 1.10.4 and kernel 4.x. Any ideas or hints on what might be causing this? The pipeline seems to be running fine.

Regards,
Danny

------------------------------

HI Danny,

I am facing a similar problem. I developed a platform for RTP/UDP streaming with gst-launch with which streams audio to a number of clients, where I do further DSP processing using LADSPA plugins before sending the processed audio to one or more alsasinks on each client.

As part of an upgrade for the LADSPA capabilities I made use of some of the "audioXXX"  elements, such as audiointerleave, audiomixer, etc. Even with latencies on the RTP jitterbuffer element and sinks that are NOT low, this resulted in buggy behavior. Sometimes when I launch the send and receive pipelines both will go into PLAYING state but no audio is produced. Sometimes the audio is garbled or stutters, either from the start or transitions from playing properly to that behavior. Then sometimes the audio works fine, and might seem to be working properly for hours or days. Then by chance the wheels fall off and it becomes problematic again.

I was able to get reliable playback by reverting all the "audioXXX" elements back to their non-audio equivalents, e.g. audiointerleave-->interleave, audiomixer-->adder, etc. It seems these "audio" elements are not yet stable (they are part of the "bad" plugins after all). That's unfortunate, because I really wanted to make use of their synchronization properties.

If you are using any of these elements, try to eliminate them and see if the problem disappears.

I have not been successful using this list to get any help to these problems, since all my posts went unanswered. Using the non-audio elements was the only way I was able to remedy the situation.

Charlie


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

RE: alsasink underrun recovery issue in a synchronized streaming

danny.smith
Hi Charlie

Thanks for the suggestions! Unfortunately we do not use these elements so
our problem remains.

Regards,
Danny



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

RE: alsasink underrun recovery issue in a synchronized streaming

Charlie Laub
Hi Danny,

I want to correct my earlier post about problems with the "audio" elements. I figured out the source of the problem: it was due to audiointerleave. This element has a property "latency" which defaults to zero. The description of the audiointerleave property is:
Additional latency in live mode to allow upstream to take longer to produce buffers for the current position (in nanoseconds)
Flags : Read / Write
Default value : 0

This was creating an intermittent problem with my pipelines. Sometimes no latency is needed, and the pipeline would function properly. Other times the streams being interleaved were not totally synchronized, so some latency was needed to buffer one or more of them until all can be interleaved in sync.

Unfortunately, I did not even realize that audiointerleave had the latency property. This is because the documentation for audiointerleave at gstreamer.freedesktop.org doesn't mention it. Only after I recently discovered documentation at thiblahute.github.io was I able to know about it.
Here is a link to that site:
https://thiblahute.github.io/GStreamer-doc/plugins_doc.html?gi-language=c

I looked at the Bugzilla link you provided in another reply. It mentions pipelines running alsasrc or updsrc stop working after a few hours. I have not experienced this over many hundreds of hours of rtp streaming over udp with my gstreamer based system.

-Charlie


-----Original Message-----
From: gstreamer-devel [mailto:[hidden email]] On Behalf Of danny.smith
Sent: Thursday, March 1, 2018 5:22 AM
To: [hidden email]
Subject: RE: alsasink underrun recovery issue in a synchronized streaming

Hi Charlie

Thanks for the suggestions! Unfortunately we do not use these elements so our problem remains.

Regards,
Danny



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel