If m-s-r sets the device we let it do so. Otherwise we handle the routing. We run before
module-intended-roles as the priority list will likely be configured appropriately
to do the same job, albeit with manual setup.
If the user has not (via our protocol extension) renamed a device, but it happens to now have
a different name (e.g. module-combine automatically updating the description for us or udev-db
getting better etc.) then make sure we update our cache with this updated version.
If the user has set a name, enforce it's use, even if the description is updated by some other
means (e.g. the user manually editing the proplist or another module doing it for them).
* Do not read or set the save_sink/save_source flags. This seems to be for module-stream-restore only...
* Even if a sink is already set by an earlier module, still move it to the sink we dictate.
* Fix a s/sink/source/ copy paste issue when dumping the database.
* Only show priority list when routing is enabled (as the list is not updated if not)
* Fix a memory access issue when finding the highest priority sinks/sources
* key name->device name efficiency fix.
* Silence noisy debug on reorder - it seems to work :)
* Reroute after reordering.
* Initialise preferred lists to PA_INVALID_INDEX
We put in the devices from the wire into a hashmap and then add all like type device in the database
and then order them based on priority (with the ones specified on the wire always being in that order at
the top of the list.
We do not handle the _EVENT_NEW subscription here as the PA_CORE_HOOK_SINK_INPUT_NEW/PA_CORE_HOOK_SOURCE_OUTPUT_NEW
hook should handle the initial routing.
This is incomplete, it just adds the slots in question and assigns noops to them.
Some minor cleanup of types.
Due to the priority of the hooks, it seems we can actually coexist with module-stream restore so
the code to detect and unload it will be removed shortly.
The structure itself will contain various bits of info so exposing this fully to the client is a bad idea.
By keeping to a rename operation we keep what we do store abstracted from the clients.
Also fix some doxy comments.
This allows clients to edit the priroity order. What is not yet in place is the initialisation of that priority list
when new devices are detected or the cleaning (remove holes) when devices are removed.
In order to keep the storage transparent I will likely remove the write functionality and replace it with a
simple rename method.
I also still need to expose the priority itself when reading the data.
The routing logic itself does not yet exist, but the command currently will unload/load module-stream-restore as approriate.
(module-stream-restore would conflict with the role-based priority-routing).
There is not technically a bug here due to the early return and the knowledge that one of the if blocks
will definitely be run, but this makes sure we don't call free on uninitialised data or do
anything else suitibly daft. Also helps when you copy the code and change it slightly and don't realise
you've left things open...
