User can attempt to load a project into room with fewer ports than the
room where project was saved. This was causing ASSERT:
Wed Dec 1 04:36:45 2010: ERROR: callback_elstart: Cannot find room link port.
Wed Dec 1 04:36:45 2010: ERROR: callback_elend: ASSERT(context_ptr->port != NULL) failed. function callback_elend in ../daemon/room_load.c: 652
This changeset fixes the ASSERT by failing the project load.
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.
This will allow expansion of env vars used in commandline to happen
when apps are started in terminal. It already happens when apps are
started without terminal.
This breaks the default title, at least for xterm. For it, it is now
set explicitly.
Starting through shell is not used when there is no '$' in the
commandline. This should minimize the title problems when xterm is not
used.
This is a workaround (that was implemented before too). The proper way of handling this is to
create 'unnamed project' when a connection or app is added to the room.
The project state now is can now have more than one state. The project
unload sequence now first removes all connections, then stopps all
apps, and as last step - clears the graph. When project load fails,
ladish_room_unload_project() is not called anymore, because unloading
of room even without apps is now a multistep process. Instead, a new
function, ladish_room_clear_project(), is introduced. It is called
when project load fails and as last step in project unload.
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.
For clients, save the naming scheme used. sometimes it is useful to maintain the original jack or alsa client name.
For ports, save port type and direction, alsa ports can be bidirectional, this renders as two a2j ports.
* 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.
Nedko Arnaudov
Nikita Zlobin