GNOME Bugzilla – Bug 567656
We need a generic profile interface that can be implemented by gconfaudiosink and pulsesink
Last modified: 2013-08-19 11:17:05 UTC
Currently the gconfaudiosink defines GstGConfProfile for the "profile" property that can be used to tag a stream as "sounds", "music" and "chat". In pulsesink we'd like to use the same kind of informatin to tag our streams as a "role". PA has a bigger vocabulary however: video, music, game, event, phone, production, animation. Also, ensonic mentioned on IRC this should be a generic interface, not a propriatary property of just GstGConfProfile. Then, I believe to make extension of this easier this should not be an enum but a string. FInally I wonder how much this actually overlaps with the tagging stuff (as in ID3). I believe that the "Profile" (or "role" in PA talk) should be a property of the stream, not the app.
If we use strings, we would need to allow to register them, so that they get a meaning and can be mapped. GConfAudioSink could e.g. map both video and music to music , with is defines and "music and movies" and imho badly named. Dunno if a sink for window vista could use this too and what profiles are available there. Means thsi needs some feedback from other people too :)
For "Registering" them all that is necessary should be adding a code comment or so of the available vocabulary. The advantage over enums is that they can be "backported" without real code changes if you understand what i mean. Dunno about vista.
# cat /usr/share/applications/totem.desktop | grep Categories Categories=GNOME;GTK;AudioVideo;Video;Player;X-Ximian-Main;X-Red-Hat-Base; # cat /usr/share/applications/rhythmbox.desktop | grep Categories Categories=GNOME;GTK;AudioVideo; # cat /usr/share/applications/empathy.desktop | grep Categories Categories=GNOME;GTK;Network;InstantMessaging; I wonder if we can get the categories somehow via GDesktopAppInfo *dainfo; dainfo=g_desktop_app_info_new(g_get_prgname()); but GAppInfoIface seems to not cover it :/
Filed Bug #567721 for glib to expose more desktop file details.
The problem I have with relying on .desktop files for this is that it the role should be a per-pipeline, not a per-process setting.
Why can't we just have a string property on both gconfaudiosink and pulsesink name "profile"? Then the application can set the profile string if the property exists, otherwise it won't so anything. Similarly, why can't pulsesink have a "stream-name" property instead of trying to be clever and figure out the stream name from the tags on the bus. This works fine for things which actually do have tags, but Jokosher is usually playing more than one file at once, and often PulseAudio just shows the stream name as "audiotestsrc wave" because we use an audiotestsrc for background noise in the pipeline. I'd much rather have a property so Jokosher can give PulseAudio the project name for the stream name.
Laszlo: sure, gst-pulse should allow that. The question however is whether this should be kept something that is specific to the pulse backend or usable in a more generic fashion.
(Btw, besides the 'profile' of a stream it would be good to have more meta data an app can assign to a stream. For example, an API for attaching a stream to a GtkWidget would be very useful to have. http://0pointer.de/lennart/projects/pulseaudio/doxygen/proplist_8h.html shows the the full list of stream properties PA can currently make use of. Some of these are gathered automatically already, but a big chunk of it can only be attached to a stream if the app explicitly does that.)
If we want to go the GAppInfo route, we would need gst_init() to call g_app_info_create_from_commandline() and gst core offers api to request it. Then e.g. pulsesink/src can use that to get the appinfo and then call g_app_info_get_id() to get the desktopfile id, fetch the desktop file and parse it. Or we simple add a "media.role" string property to pulsesink/src and document the possible values in the form of a link to pa-spec.
(In reply to comment #9) > If we want to go the GAppInfo route, we would need ... I don't think we want to go down the GAppInfo route though, do we? AIUI Lennart suggested this setting should be per-stream or per-pipeline, not per-app, which seems to make more sense to me as well.
Any news ideas on this bug? I have to agree that a per-pipeline setting is better though
Maybe GstContext could be used for this? :)
> Maybe GstContext could be used for this? :) Ew :) I think this bug is more generic really, we should be able to assign "roles" or so to pipelines/bins, and have it propagate, so that elements can make smarter decisions about what to do by default in some situations.
I wonder if we still need that. GConfAudiosink is gone and GSettingsAudioSink is not favored by the gnome desktop even.
pulsesink still needs this for example.
IMHO an interface is mostly interesting if it can be implemented by multiple elements (also it is easier to design the iface if you have multiple potential implementations). For pulsesink one can use the env-vars or the "stream-properties" object prop.
Ok, so let's just get rid of this bug for now then.