[Bug 692953] alsa modules are silent or noisy after several hours of use

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=692953
  GStreamer | gst-plugins-base | 1.0.9

--- Comment #62 from Thomas DEBESSE <thomas.debesse at rcf.fr> 2013-08-26 18:48:30 UTC ---
> So, from you testing, the pipeline below should eventually fail?
> gst-launch audiotestsrc ! audioconvert ! audioresample ! alsasink

I will try it. :)

But bad news, I forget that the pipeline failed in Comment #35 was:

gst-launch-1.0 -v alsasrc device="$alsa_iface" ! queue ! alsasink
device="$alsa_iface" sync=false

WITHOUT audioconvert and without audioresample.

I have at least ONE CASE of failed pipeline that does not use audioresample nor
audioconvert. This pipeline has failed in less than 15 hours.

This one was running on Gstreamer 1.0.6 with a non-realtime linux kernel (the
'g' computer)

The tests running in Comment #22, Comment #48 and Comment #55 are running on
Gstreamer 1.0.9 with a realtime linux kernel (the 'b' computer).

It seems that realtime kernels give more time before the bug appears, but it's
just a feeling (not proved).

> What about trying...
> gst-launch alsasrc latency-time=20000 buffer-time=800000 !
> audioresample ! audioconvert ! alsasink sync=false

I have already test this kind of options in the past, but I do not remember the
results.
I will retry it. But it is not good For my usage to lengthen the recording and
playback time. If it help to contain the bug, I do not consider this to be a
good solution. The Gstreamer alsa latency-time and buffer-time default values
(10ms of latency-time and 200ms of buffer-time) are already oversized.
In comparison, a typical jackd latency is 6ms, and works on USB soundcard (USB
soundcards are known to have a lot of latency). Default values (10ms latency
and 200ms buffer are listenable and are already unpleasant).

IRL I use 6000 microsecond of latency time (6ms), and it works for hours before
the crash. In this talk all the tests was done with default values (10000
microsecond latency-time, 200000 microsecond buffer-time), and it works for
hour before the crash. Why can it work more than 12 hours with 6ms, but not 13h
(for example, or why 20h but not 21h, why one day but not two days)?

IRL, this command
arecord -D hw:CODEC -f dat | aplay -D hw:CODEC -f dat
is faster than this command
gst-launch-1.0 alsasrc ! capsfilter caps="audio/x-raw, format=S16LE,
rate=48000, channels=2" ! alsasink
By the word "faster" I mean the latency between recording and playing is
smaller.

Thoses two commands are equivalent in terms of functionality, but the in the
first, record and aplay both hide a software resampler and format converter
(there is therefore two hidden resamplers and two hidden converters) that
Gstreamer don't use without explicit call, and the first command use the
unsuitable unix pipe. 10ms is already more than necessary, a legitimate prudent
choice.

Perhaps latency-time can extend or reduce the time before a pipeline fails,
like usage of rt-kernel or non-rt-kernel, but I do not think this solves the
problem, perhaps it makes the problem more difficult to solve because it takes
longer to identify the bug.

But above all, having a failed pipeline (in less than 20 hours) that did not
use audioconvert not audioresample makes it all confused. All these options
seem to change the time it starts to fail, but not really fix the problem.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.