Bug 72523

Summary: Refactoring idea: change sink and source ownership from the card back end implementation to pa_card
Product: PulseAudio Reporter: Tanu Kaskinen <tanuk>
Component: coreAssignee: pulseaudio-bugs
Status: RESOLVED MOVED QA Contact: pulseaudio-bugs
Severity: normal    
Priority: medium CC: lennart
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description Tanu Kaskinen 2013-12-09 14:55:53 UTC
When a sink or source belongs to a card, I think it would be a good idea to make pa_card the owner of the sink or source. This would mean that pa_card would decide when to create and destroy sinks and sources (they would be created at profile activation and destroyed at profile deactivation). I think this would make a lot of sense conceptually, but I'm not whether the effects on the back end complexity would be positive or negative (I would expect a positive effect).

The unclear part is how to delegate the back end specific parts of the sink initialization (and deinitialization) to the back end, if pa_sink_new() is called from card.c. I don't think we currently have any similar object initialization scheme in PA.

This idea occurred to me while implementing device prototypes. It's annoying that card back ends need to explicitly link the device prototypes with the sink or source whenever the back end creates a sink/source. It's only one line per created sink/source, but still it feels like unnecessary boilerplate code. If pa_card controlled the sink and source creation, the common code in card.c could take care of hooking the sinks and sources to the corresponding device prototype.
Comment 1 GitLab Migration User 2018-07-30 10:36:51 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/530.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.