Created attachment 153849 [details]
the failing log

Bugzilla won't let me attach very big files, it seems. heh

Here's the passing log:

http://people.collabora.co.uk/~kov/passing-log.gz

 I am filling it under core, but it seems likely that this is something else failing, I'm leaving assigning it properly to your judgement, since I'm not really sure. Also, please let me know of ways I can provide more useful information.

That does not look like a bug to me:

0:00:00.732456081 16454      0x21b0410 DEBUG             autodetect gstautoaudiosink.c:303:gst_auto_audio_sink_find_best:<audiosink> error message error message from element 'audiosink-actual-sink-alsa': GstMessageError, gerror=(GstGError)NULL, debug=(string)"gstalsasink.c\(686\):\ gst_alsasink_open\ \(\):\ /GstAlsaSink:audiosink-actual-sink-alsa:\012Device\ \'default\'\ is\ busy";

So basically the audio device on the computer is in use and no other device works, so autoaudiosink errors out and that's that. Seems like expected behaviour to me. (You should ignore all error messages on the bus after the first error).

You may want to configure playbin2 with audio-sink="fakesink sync=true" or "alsasink device=null" or so.

(In reply to comment #3)
> So basically the audio device on the computer is in use and no other device
> works, so autoaudiosink errors out and that's that. Seems like expected
> behaviour to me. (You should ignore all error messages on the bus after the
> first error).

That makes sense to me, except for the fact that the other audio tests pass, and that just downgrading gstreamer makes this specific test pass again (both in my machine, and in the buildbot, which uses the dummy kernel module). Also, I can play audio files with aplay.

Does the gst-launch command from bug #608036 work for you?

oh nevermind, I guess that will only work with -bad from git.

(In reply to comment #6)
> oh nevermind, I guess that will only work with -bad from git.

I'll build the whole gstreamer stack from git to be able to help track these, I'll get back to you on this =)

Any news on this?

Yes having a "failing" log using a correct audio sink would maybe help here.

Unmarking as blocker, since we still don't have a bug description in GStreamer terms as far as I can tell, and no one's working on this (and I'm guessing Philippe can't reproduce this either, otherwise he wouldn't have asked for a failing log).

Just like 610025, this regression seems to have been introduced by this commit:

commit af34d2c1f8c70c9e02d0621a5b72003164fba759
Author: Sebastian Dröge <sebastian.droege@collabora.co.uk>
Date:   Wed Nov 18 09:22:39 2009 +0100

    playbin2: Don't handle DURATION queries during group switches

    During a group switch return the cached duration of the old group
    because the old group still didn't finish playback. If we have no
    cached duration return FALSE.

    Fixes bug #585969.

I just finished bisecting this one (I bisected them separately).

Reopening as I can't see any open question.

The question is: what's the problem in GStreamer terms? ie. why is this a bug in GStreamer and not in webkit's gstreamer code or the webkit unit tests, and what is the bug/regression?

Also: does this still happen with recent versions?

I don't know what to do about this, we still don't have a description of the problem in GStreamer terms. Could just as well be a bug in the test suite. Without more details, we can't do anything about this, so closing this for now. Please re-open if you have more for us to go on.

For the record, the WebKitGTK buildslaves now have latest gstreamer release and the test runs fine.