vgraph clients that are created by a2j port appear and are later
reused for native jack ports are now interlinked with the jack
client when the first jack port appears.
If the app first creates alsa (a2j) port, the created vclient is
not intrelinked because there is no jack client to interlink.
When the first jack port appears, because the jack client has
no interlinked client, a new vclient with same name was created.
This changeset implements a search by app uuid before new vclient
is created.
This fixes handling of apps that use random alsa client names.
jack-rack for example, by default, uses PID as part of its
alsa client name.
This breaks backward compatibility.
For real jack ports it works because different apps have different jack client.
For a2j ports, it did not work because the jack client is same and the
a2j_fake_jack_port_name is same too, because the instead of alsa client name,
the app name is used now
For studio saves, save only studio vgraph a2j ports.
For room project saves, save only room vgraph a2j ports.
If there is not a2j ports for the vgraph being saved, an empty a2j client will not be saved anymore
a2j client has not app associated and thus should never be returned by ladish_graph_find_client_by_app()
This was somewhat possible in past, when the client was searched by name and not by uuid.
Also is_empty var is removed for ladish_graph_find_client_by_app(). For ladish_virtualizer_remove_app(),
the is_empty var is kept, because ladish_graph_client_is_empty() cannot be called after the client is removed
from the jack graph.
* normal jack clients have both app_uuid set and non-zero pid
* jmcore clients have only non-zero pid, their app_uuid is null
* clients of unmanaged apps (externally started aps, inprocess clients
and the a2j client) have zero pid and zero app_uuid
Same or derivate project can be loaded in more than one room. This will cause more than one port
with given uuid to be added to the jack graph. This changeset uses vgraph-port_uuid pair when searching
for port that was added at earlier project load stage. For this to work, when ports are created and added
to the jack graph, the vgraph handle is stored in the port object.
This fixes a bug when port is appearing, connect attempt is made,
connect fails because port has just disappeared, port reappears then
but new connect attempt was not made. Happens quite easily with
wineasio apps that "probe" (nuendo2 for example).
If the first JACK client that appears has pid different from the one
of the child process, send SIGUSR1 on L1 save to this first
grandchild.
This changeset fixes the "run L1 app in terminal" issue and the
similar issue with dash (the default shell on Debian and Ubuntu, that
for simple commandlines does fork() and exec() instead of just exec(),
like bash does. This changeset also fixes the situation with complex
commandlines that result in only one JACK client.
The complex commandlines that result in multiple processes creating
JACK clients are handled by sending the SIGUSR1 to the first process
that creates JACK client. In future this could be improved by sending
SIGUSR1 to all of them but it is probably better to avoid such
situations by creating one app per JACK-creating process.
Don't use jack ids for associating client in jack graph with client in vgraph
because jack ids can change (apps can create clients in random order).
jack ids are not valid after jack server stop
This changeset switches to interlinking the two client by each one storing uuid of the other.
Nedko Arnaudov