[LAU] getting gstreamer and jack to play ball

[theo]

On 02/01/2016 05:12 PM, Paul Davis wrote:
>
>
> On Fri, Jan 29, 2016 at 6:29 PM, Neil C Smith 
> <neilcsmith.net at googlemail.com <mailto:neilcsmith.net at googlemail.com>> 
> wrote:
>
>     On 29 Jan 2016 22:47, "theo" <theo_linuxaudio at borm.org
>     <mailto:theo_linuxaudio at borm.org>> wrote:.
>     > - 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.
>
>

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20160203/a57eb644/attachment.html>