3 Feb
2016
3 Feb
'16
1:03 a.m.
On 02/01/2016 05:12 PM, Paul Davis wrote:
On Fri, Jan 29, 2016 at 6:29 PM, Neil C Smith
<neilcsmith.net(a)googlemail.com <mailto:neilcsmith.net@googlemail.com>>
wrote:
On 29 Jan 2016 22:47, "theo" <theo_linuxaudio(a)borm.org
<mailto:theo_linuxaudio@borm.org>> wrote:.
Hi,
Sorry for the late reply. Got a lot of work dumped on my desk.
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.
Thanks a lot for the excellent hints. I had a look at the GStreamer
properties and control=0 indeed does the job.
for posterity:
I edited properties using gconf-editor. By setting the following keys:
system->gstreamer->0.10->default->audiosink
system->gstreamer->0.10->default->musicaudiosink
both to
jackaudiosink buffer-time=2000000 connect=0
(or jackaudiosink buffer-time=2000000 connect=none)
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).
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)
thanks again.
cheers, Theo
- 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.
Well, in some ways it does, depending on how you're using
GStreamer. I've been having fun with this issue recently too.
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.
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".
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.
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.