pa_sink_get_formats() returns a freshly allocated idxset with freshly allocated format info objects every time it's called. In my opinion this is waste of CPU cycles, and also makes life harder for the callers of the function, because they have to free the returned formats.

Currently the sink formats are stored inside the sink backend code. The formats could also be stored in the pa_sink struct, in which case the whole pa_sink_get_format() function could be removed (there's some point in keeping the getter function for encapsulation reasons, though, but I'd prefer not to keep it). If the formats are stored in pa_sink, then that raises a question how pa_sink_set_formats() would work. The sink backend should still handle that operation, but would the backend write directly to pa_sink.formats, or should it be done in some other way? I personally would prefer to do it in some other way, because while I slightly dislike getter functions, I do like setter functions, so the backend shouldn't write directly to fields in the pa_sink struct.

What would the "setter function" be called? pa_sink_set_formats() is a no-go, because that's the function from which the setter function would be called. I propose that pa_sink_formats_changed() is added. It would be called by the sink backend when the formats change in the backend, similarly how pa_sink_volume_changed() and pa_sink_mute_changed() are called when the volume/mute changes in the backend.