GNOME Bugzilla – Bug 627174
[pulsesink] new property to tune the PA client name
Last modified: 2010-09-04 13:12:13 UTC
Related to bug 623121, it'd be nice to be able to configure the PA client name with a GObject property on the pulsesink.
I started a patch but it doesn't seem like the pa_context name can be updated after the context creation. What should we do in the case where pulsesink::client is updated after the element reached READY ?
(In reply to comment #1) > I started a patch but it doesn't seem like the pa_context name can be updated > after the context creation. What should we do in the case where > pulsesink::client is updated after the element reached READY ? Nothing.. the client name will be used when the pulsesink goes to ready the next time.
(In reply to comment #2) > Nothing.. the client name will be used when the pulsesink goes to ready the > next time. ah, and you can use GST_PARAM_MUTABLE_READY to indicate that this property can only be changed in ready or lower.
We don't have the GST_PARAM_MUTABLE_READY, etc patch because the implementation was racy
Created attachment 168204 [details] [review] pulsesink: new "client" property Allow application-side to modify the client name used to connect when connecting to the PulseAudio daemon. Note however that updating the property after the element reached the READY state will have no effect. Fixes bug 627174
(In reply to comment #4) > We don't have the GST_PARAM_MUTABLE_READY, etc patch because the implementation > was racy So I shouldn't use it? It's not used in this first version of the patch. If it's racy and not reliable why is it used? I see at least filesrc using GST_PARAM_MUTABLE_*
(In reply to comment #4) > We don't have the GST_PARAM_MUTABLE_READY, etc patch because the implementation > was racy I wouldn't know why it would be racy. It's a flag that never changes and that tells the app that this property needs to be changed in READY or less. It's up to the app to change it in those states. I can understand that when the element is going through various state changes in another thread that it might be difficult for the app to predict the state of the element but since those state changes are always triggered by the app, it can solve this problem.
Apparently you're right. I thought those macros were removed again but apparently my memory was wrong and they're there and only the functions for checking in set_property if the element is in the correct state were removed. Sorry for the confusion
Ok then, will upload a new patch tomorrow :)
You should also initialize the client name in the instance init function to something useful, i.e. not NULL :) And maybe, if in set_property NULL is passed, you could reset it to the default value instead. I don't know how happy pulseaudio is with a NULL client name.
Created attachment 168291 [details] [review] pulsesink: new "client" property Allow application-side to modify the client name used to connect when connecting to the PulseAudio daemon. Note however that updating the property after the element reached the READY state will have no effect. Fixes bug 627174
Could you rebase your patch against a pulsesink with all the other changes? :)
(In reply to comment #12) > Could you rebase your patch against a pulsesink with all the other changes? :) You mean the changes you modified in your local repo? ;) I don't mind waiting the freeze end for this patch and send a rebased patch when the other changes have landed mainstream.
Comment on attachment 168291 [details] [review] pulsesink: new "client" property Ok, I merged it myself now and will push it after release :)
commit 7116fff3c59c1ac82cebb3a7bc4c8584fd436190 Author: Philippe Normand <pnormand@igalia.com> Date: Wed Aug 18 16:37:41 2010 +0200 pulsesink: Add "client" property to set the PA client name Allows the application to modify the client name used to connect when connecting to the PulseAudio daemon. Note however that updating the property after the element reached the READY state will have no effect until the next NULL->READY transition. Fixes bug #627174.