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 555346 - jackaudiosink doesn't have GstPropertyProbe
jackaudiosink doesn't have GstPropertyProbe
Status: RESOLVED INVALID
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other All
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks: 335105
 
 
Reported: 2008-10-07 06:38 UTC by Snark
Modified: 2008-10-10 12:31 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Snark 2008-10-07 06:38:22 UTC
How can one know which devices are available?
Comment 1 Wim Taymans 2008-10-07 08:36:08 UTC
I don't think the jack API has anything for that. You start the server on a device and that's it.

Reopen if you disagree.
Comment 2 Snark 2008-10-07 18:59:11 UTC
Uh... should I just see if jackaudiosink (and jackaudiosrc, since indeed it exists -- sorry) is available and just make "Jack" available to the user?
Comment 3 Stefan Sauer (gstreamer, gtkdoc dev) 2008-10-09 19:00:12 UTC
the only thing a property probe could provice is the available peer targets, e.g. other apps or the real audio ports. but in that case we would also add the capability to connect to the specified link.

Snark, what happens right now, is that one need to use e.g qjackctrl to link the virtual port that jacksrc/sink create to something.
Comment 4 Snark 2008-10-10 03:25:50 UTC
Uh... this looks 100% insane to ask our users... I'm closing the ekiga bug as WONTFIX if the framework is that unfriendly.
Comment 5 Wim Taymans 2008-10-10 08:29:24 UTC
I disagree, jackaudiosink automatically connects its ports to available playback/recording ports in jack. There is an option to not do this and let the user manually connect the ports with qjackctrl or with srcipts.

A property probe is only useful for detecting the available devices, which the jack api does not provide AFAIK. 

Maybe it can also be used to find all available running jack servers but I have no idea if that is possible.
Comment 6 Snark 2008-10-10 10:53:43 UTC
What do you disagree exactly with? I find it insane to have ekiga users choose "Jack" in ekiga, then launch another program to connect what was opened with a device...

Oh, perhaps you mistook "the framework is that unfriendly"? It was about jack, not about gstreamer : I'm pretty happy with the gstreamer framework -- it's very nice  :-)     (though it would be better if GstAppSink&GstAppSrc were more complete and in the base)
Comment 7 Wim Taymans 2008-10-10 11:20:23 UTC
I disagree with the fact that you need to use another program to connect to jack. Just run jackd on the device you choose with the format you choose and gstreamer will automatically output to it.

I agree that letting the user select jack as a sink is insane. Setting up jack is non-trivial but when it's setup correctly things will just work with the jackaudiosink.

I would also suggest to use autoaudiosink, it will probe and use the best audiosink for the currently running system. Letting the user choose alsa if there is no alsa configured is silly.
Comment 8 Wim Taymans 2008-10-10 11:21:57 UTC
Oh, what's pending for appsrc/appsink?
Comment 9 Snark 2008-10-10 12:31:25 UTC
Well, autoaudiosink might sound nice, but our users want to have the ringing sound on a loud device when they're away from the computer, and the call audio in their headset... so we really need to be able to choose more finely.

See bug #413418 to see what's pending for GstAppSink&GstAppSrc.