[Bug 692953] alsa modules are silent or noisy after several hours of use (Gst 0.10.30 and Gst 1.0.4)

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #7 from Thomas DEBESSE <thomas.debesse at rcf.fr> 2013-08-21 12:26:04 UTC ---
> Is it enough to set the pipeline back to PAUSED
> and then PLAYING to make it work again? Or is
> NULL really required?

NULL seems required.

> Are the source and sink both on the same physical
> device, thus sharing a hardware clock?

The "alsasrc ! … ! alsasink" pipeline is only for demonstration purpose : the
bug appears *also* with this pipeline, and I can verify the bug with this
simple pipeline putting a physical source and physical monitor to ear sound (or
not due to the bug when the bug appears :) ).

But I have tested thoses pipelines (written from memory, you get the idea) :

1. Using alsasrc without alsasink

alsasrc ! something

2. Using alsasink without alsasrc

something ! alsasink

3. Pipelining alsasrc to alsasink with same interface

alsasrc device="hw:0" ! something ! alsasink device="hw:0"

4. Pipelining alsasrc to alsasink with different interface

alsasrc device="hw:0" ! something ! alsasink device="hw:1"

5. Using alsasrc or alsasink using dmix or dsnoop alsa module (software mixer
to not monopolize the interface)

alsasrc device="dsnoop:hw:0" ! something
something ! alsasink device="dmix:hw:0"

6. Using alsasrc or alsasink using plug alsa module (resampling and conversion
done on the alsa side)

alsasrc device="plug:hw:0" ! something
something ! alsasink device="plug:hw:0"

7. Using alsasrc and/or alsasink with a combination of plug and dmix alsa
modules.

alsasrc device="intel_in" ! something

with that in ~/.asoundrc :

---8<------------------------------------
pcm.intel_in {
    type plug
    slave.pcm {
        type dsnoop
        ipc_key 1024
        slave {
                pcm "hw:1,0" 
        }
    }
}
---8<------------------------------------

8. Using alsasrc and/or alsasink with audioconvert and audioresample Gstreamer
module

alsasrc ! audioconvert ! audioresample ! something

9. Using alsasrc and/or alsasink with audioconvert and audioresample Gstreamer
module plus plug and/or dmix or dsnoop alsa module

alsasrc device="intel_in" ! audioconvert ! audioresample ! something

10. using same interface with same format and same sampling

11. using same or different interfaces (with or without alsa module) with
forced different format and/or sampling

alsasrc ! 'audio/x-raw, format=S16LE, rate=44100' ! audioconvert! audioresample
! 'audio/x-raw, format=F32LE, rate=96000' ! audioconvert ! audioresample !
'audio/x-raw, format=S16LE, rate=48000' ! alsasink

(Or something like that)

12. using similar pipeline but changing only the alsasrc or alsasink module

with bug : 

alsasrc ! audioconvert ! audioresample ! 'somecaps' ! opusenc ! rtpopuspay !
udpsink

without bug :

jackaudiosrc ! audioconvert ! audioresample ! 'somecaps' ! opusenc ! rtpopuspay
! udpsink

All the modules used in the pipelines using alsasrc or alsasink module where
tested in another pipelines without alsasrc or alsasink module, and the bug
appears only with the alsasrc and alsasink modules.

IRL, I use more complexe scenario like that :

alsasrc ! something ! jackaudiosink → (jack patchbay with multiple jack
clients, some of them doing) → jackaudiosrc ! something ! opusenc ! rtpopuspay
! udpsink → (network) → udpsrc ! rtpjitterbuffer ! rtpopusdepay ! something !
jackaudiosink → (another jack patchbay with multiple jack clients, some of them
doing) → jackaudiosrc ! something ! alsasink

I am streaming sound over the network from and to multiple distant sites with
jack pachbay on each sites and some alsasrc / alsasink modules dynamically
plugged or unplugged to the jack patchbay.

The pipeline "alsasrc ! something ! alsasink" is only a reduced testcase which
is sufficient to find the bug. :)

Note : I always use "sync=false" when pipelining alsasrc or alsasink module
with another realtime module (like pipelining alsasrc with alsasink or alsasrc
with jackaudiosink, for example). I've never had good sound (noisy, silent or
jerky) using "sync=true" with the alsasrc module or the alsasink module.

The bug only appears in very long waiting. For example I'm trying to run a test
for more than 18 hours to make a backtrace as requested here:

http://gstreamer-devel.966125.n4.nabble.com/long-run-gstreamer-stops-working-without-message-td4655520.html#message4661617

But the bug is not yet appeared (but sometimes the bug appears even in only
three hours, it is variable)…

It is difficult to track ! :)

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