[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.6

--- Comment #15 from Thomas DEBESSE <thomas.debesse at rcf.fr> 2013-08-21 21:31:21 UTC ---
OK. I have the another computer with plenty of soundcards! :)

*********** first computer:

** hw:0 / hw:Intel (Integrated PCI HDA Intel 82801H)
shell$ gst-launch-1.0 audiotestsrc ! alsasink device=hw:0

state: running at this time. Is this pipeline will survive ?

** hw:1 / hw:H2n (USB-Audio ZOOM Corporation H2n)
shell$ gst-launch-1.0 -v alsasrc device="hw:1" ! audioconvert ! audioresample !
"audio/x-raw, format=S16LE, channels=2" ! alsasink device="hw:1" sync=false

state : stuck silently

*********** second computer:

** hw:0 / hw:XFi (PCI Creative X-Fi 20K1 SB-XFi)
shell$ gst-launch-1.0 -v alsasrc device=hw:XFi ! queue ! alsasink device=hw:XFi
sync=false

state: running at this time. Is this pipeline will survive ?

** hw:1 / hw:Intel (Integrated PCI HDA Intel 82801H)
shell$ gst-launch-1.0 -v alsasrc device=hw:Intel ! alsasink device=hw:Intel
sync=false

state: running at this time. Is this pipeline will survive ?

** hw:2 / hw:Juli (PCIe ESI Juli@ ICE1724)
python3> import gi
python3> gi.require_version("Gst", "1.0")
python3> from gi.repository import Gst, GObject
python3> GObject.threads_init()
python3> Gst.init(None)
python3> mainloop = GObject.MainLoop()
python3> pipeline_src = Gst.parse_launch("alsasrc device=hw:Juli ! capsfilter
caps=\"audio/x-raw, format=S32LE, rate=48000, channels=2\" ! audioconvert !
audioresample ! capsfilter caps=\"audio/x-raw, format=F32LE, rate=48000,
channels=2\" ! jackaudiosink client-name=pipeline_src sync=false connect=none")
python3> pipeline_sink = Gst.parse_launch("jackaudiosrc
client-name=pipeline_sink connect=none ! capsfilter caps=\"audio/x-raw,
format=F32LE, rate=48000, channels=2\" ! audioconvert ! audioresample !
capsfilter caps=\"audio/x-raw, format=S32LE, rate=48000, channels=2\" !
alsasink device=hw:Juli")
python3> pipeline_src.set_state(Gst.State.PLAYING)
python3> pipeline_sink.set_state(Gst.State.PLAYING)
python3> mainloop.run()

shell$ jack_connect pipeline_src:out_jackaudiosink0_1
pipeline_sink:in_jackaudiosrc0_1
shell$ jack_connect pipeline_src:out_jackaudiosink0_2
pipeline_sink:in_jackaudiosrc0_2

I have two pipelines, one for recording (alsa to jack), one for playing (jack
to alsa), they are independent.

state: running at this time. Is this pipelines will survive ?

** hw:3 / hw:Live (PCI Creative SB Live! PCI512 [CT4790] EMU10K1)
(doing nothing for the moment, available for testing without interrupting other
current tests)

** hw:4 / hw:Live1 (PCI Creative SB Live! Value [CT4832] EMU10K1)
(doing nothing for the moment, available for testing without interrupting other
current tests)

** hw:5 / hw:CODEC (USB-Audio - USB Audio Behringer UCA202 PCM2902 CODEC)
shell$ arecord -D hw:CODEC -f cd | aplay -D hw:CODEC -f cd -vv -V stereo
2>/dev/null

It's an equivalent to "alsasrc device=hw:CODEC ! audio/x-raw, format=S16LE,
rate=44100, channels=2 ! alsasink device=hw:CODEC" plus this give to me a
minimalistic vu-meter. If I plug any soundcard output to this USB soundcard, I
will have an audio level on the vu-meter plus sound on the output. (Note: I've
never seen this command having a bug).

I will tell you in 20 hours, which will happened to these tests.

If someone have an idea to analyze the pipeline that is currently blocked, feel
free. :)
(I can publish a core dump of the stuck pipeline, too)

-- 
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.