After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 440161 - alsasink element can be used only one time per program
alsasink element can be used only one time per program
Status: RESOLVED INVALID
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other All
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-05-21 12:35 UTC by Artem Ignatiev
Modified: 2007-05-25 09:43 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
Testcase program (1.28 KB, text/plain)
2007-05-21 12:39 UTC, Artem Ignatiev
Details
results of test program with --gst-debug=5 (184.85 KB, application/x-gzip)
2007-05-21 12:40 UTC, Artem Ignatiev
Details
Debug-log for gstreamer 0.10.11 (165.62 KB, application/x-gzip)
2007-05-22 10:39 UTC, Artem Ignatiev
Details

Description Artem Ignatiev 2007-05-21 12:35:44 UTC
Please describe the problem:
I can run pipeline with alsasink only one time. After unref-ing the pipeline, and creating new one with alsasink the new pipeline won't go into PLAYING state. ringbuffer hangs in opening device.

On the other hand, works fine with OSSsink or previous version (gst-plugins-base 0.10.11)

Steps to reproduce:
Testcase: (http://timon.stabilis.ru/~timon/alstest.c)
#include <gst/gst.h>

#define GST_CREATE_EL(el, kind, name) do {				\
	el = gst_element_factory_make(kind, name);			\
	g_assert(el);										\
	g_print("Created %s of kind %s with name %s, %p\n",	\
		#el, kind, name, el);							\
	if (el != pipe)										\
		gst_bin_add(GST_BIN(pipe), el);					\
} while (0)
#define SINK "alsa"

GMainLoop *loop;
GstElement *pipe, *src, *conv, *res, *sink;
int timer = 0;

void
CreatePipeline()
{
	GST_CREATE_EL(pipe, "pipeline", "pipeline");
	GST_CREATE_EL(src, "audiotestsrc", "src");
	GST_CREATE_EL(conv, "audioconvert", "converter");
	GST_CREATE_EL(res, "audioresample", "resampler");
	GST_CREATE_EL(sink, SINK"sink", sink);
	gst_element_link_many(src, conv, res, sink, NULL);
}

gboolean
IdleTimer(gpointer data)
{
	timer ++;
	g_print("Timer: %d\n", timer);
	if ((timer % 10) == 0) {
		gst_element_set_state(pipe, GST_STATE_NULL);
		g_main_loop_quit(loop);
	}
	return TRUE;
}

int
main(int ac, char **av)
{
	gst_init(&ac, &av);
	loop = g_main_loop_new(NULL, FALSE);
	g_timeout_add(100, IdleTimer, NULL);

	CreatePipeline();
	gst_element_set_state(pipe, GST_STATE_PLAYING);
	g_main_loop_run(loop);
	g_object_unref(pipe);

	g_print("done\n");

	CreatePipeline();
	gst_element_set_state(pipe, GST_STATE_PLAYING);
	g_main_loop_run(loop);
	g_object_unref(pipe);

	return (0);
}


Actual results:
First time the pipeline runs well.
Second time the pipeline doesn't change to PLAYING state, with the last message:
0:00:02.348000000 10497 0x502010 DEBUG           ringbuffer gstringbuffer.c:443:gst_ring_buffer_open_device:<audiosinkringbuffer1> opening device.
Have to kill program using ^C.

Expected results:
Hear sample tone, then gap, then sample tone again.

Does this happen every time?
YES.

Other information:
Test program: http://timon.stabilis.ru/~timon/alstest.c
results of test run with --gst-debug=5 http://timon.stabilis.ru/~timon/alstest-cvs.log.gz
Comment 1 Artem Ignatiev 2007-05-21 12:39:08 UTC
Created attachment 88538 [details]
Testcase program

Test program I had used
Comment 2 Artem Ignatiev 2007-05-21 12:40:54 UTC
Created attachment 88539 [details]
results of test program with --gst-debug=5
Comment 3 Jan Schmidt 2007-05-21 14:31:39 UTC
From the debug log, the first alsa sink is being shut down correctly, and is closing the audio device. When the 2nd instance tries to open the device though, it's hanging. 

I'd say we can only lay such a bug at ALSA's feet - I don't see how it can be our fault.
Comment 4 Artem Ignatiev 2007-05-22 10:39:21 UTC
Created attachment 88590 [details]
Debug-log for gstreamer 0.10.11

results of the same program with --gst-debug=5 using gstreamer 0.10.11
Comment 5 Artem Ignatiev 2007-05-22 10:40:23 UTC
Comment on attachment 88590 [details]
Debug-log for gstreamer 0.10.11

Same box, same alsa, only gstreamer was changed
Comment 6 Jan Schmidt 2007-05-22 11:12:54 UTC
Hrmn, ok - which packages exactly have you reinstalled with this test? GStreamer core and/or Plugins Base? How about using Cor & Base 0.10.12 (which are the current releases)

I can't reproduce the problem on this machine, including changing the test to use ALSA hw:0 device to avoid dmix. 

I can't think of any obvious causes.
Comment 7 Artem Ignatiev 2007-05-22 11:35:19 UTC
(In reply to comment #6)
> Hrmn, ok - which packages exactly have you reinstalled with this test?
> GStreamer core and/or Plugins Base? 

gstreamer (core) and gst-plugins-base.
As I realised, that sources were from CVS, too.
I can attach CVS $Ident$ strings of gst-plugins-base/ext/alsa/* and baseaudiosink.

> How about using Cor & Base 0.10.12 (which are the current releases)

They're not in debian stable packages repository, so it'll take some time to fetch & install.

Comment 8 Artem Ignatiev 2007-05-25 09:29:15 UTC
Sorry for the noise,
Looks like something was completely b0rked in my setup.
After the box was reinstalled from scratch, the test program ran fine.

I guess the status can be changed...
Comment 9 Jan Schmidt 2007-05-25 09:43:15 UTC
Great! Thanks for the update :)