<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 02/01/2016 05:12 PM, Paul Davis
wrote:<br>
</div>
<blockquote
cite="mid:CAFa_cKn3AQwmUe=LOF_dhj2=kRxu+kspMXHfPgqt8=LVk69Fow@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Jan 29, 2016 at 6:29 PM, Neil
C Smith <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:neilcsmith.net@googlemail.com"
target="_blank">neilcsmith.net@googlemail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">On 29 Jan 2016 22:47, "theo" <<a
moz-do-not-send="true"
href="mailto:theo_linuxaudio@borm.org" target="_blank">theo_linuxaudio@borm.org</a>>
wrote:.<br>
> - What is the point of this (re-)connection
behaviour of gstreamer? - gstreamer doesn't suddenly
become a "new device" when it starts playing a new song.</p>
<p dir="ltr">Well, in some ways it does, depending on how
you're using GStreamer. I've been having fun with this
issue recently too.</p>
<p dir="ltr">This is all down to the default behaviour of
the GStreamer JACK sink. There are two properties that
can be set on it that may be useful. The first, connect,
controls whether GStreamer auto-connects to the outputs
- I think using connect=0 will stop it auto-connecting.
More recent versions of GStreamer also allow you to set
a port pattern for auto-connection, which would allow
you to control the behaviour you want without the
patchbay.</p>
</blockquote>
<div><br>
</div>
<div>Slightly more than this: almost all gstreamer-enabled
applications consider various user operations like "Stop"
(and sometimes even "Pause" and sometimes even "Next
Song") to be a point at which they disconnect from
whatever audio backend gstreamer has been told to use.
Specifically, they "close" the "device".<br>
<br>
</div>
<div>The gstreamer backend was written to disconnect from
JACK when told to "close". This behaviour makes sense if
the "device" was an actual physical device, but it doesn't
make any sense in the context of a server like JACK. <br>
<br>
</div>
<div>I did try to patch the gstreamer JACK code to not do
this, and remain connected to JACK across time and space
(so to speak) but it was harder than I was willing to deal
with.<br>
</div>
<div><br>
</div>
<div> <br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
Hi,<br>
<br>
Sorry for the late reply. Got a lot of work dumped on my desk.<br>
<br>
Well, come to think of it, maybe it is just easier coding to
close/reopen. I don't know what would happen if a program would
leave an audio device open only to find the next file to play
inaccessible or something like that. I guess that would require
extra checks. AFAIK, the close/reopen also does not result in
audible issues.<br>
<br>
Thanks a lot for the excellent hints. I had a look at the GStreamer
properties and control=0 indeed does the job.<br>
<br>
for posterity:<br>
<br>
I edited properties using gconf-editor. By setting the following
keys:<br>
system->gstreamer->0.10->default->audiosink<br>
system->gstreamer->0.10->default->musicaudiosink<br>
both to<br>
jackaudiosink buffer-time=2000000 connect=0<br>
(or jackaudiosink buffer-time=2000000 connect=none)<br>
I got playback through jack from gstreamer without the default
connection to channels 1 and 2 of my multi-output sound card. By
making the required connections (in my case to channels 3 and 4) in
the qjackctl patch bay everything just works (tm).<br>
<br>
I also had a look at the gstreamer code, and got completely bogged
down trying to set up a working gnome build environment. I'll have
to leave that for now. (It also should be noted that this is for
gstreamer 0.10 - I have no idea how this ties into gstreamer 1.0)<br>
<br>
thanks again.<br>
<br>
cheers, Theo<br>
<br>
</body>
</html>