Ticket #320 (closed bug: fixed)

Opened 12 years ago

Last modified 11 years ago

multiple instances of ffado-dbus-server prevent ffado-mixer starting

Reported by: danboid Assigned to: arnonym
Priority: major Milestone: FFADO 2.1
Component: ffado-mixer Version: FFADO SVN (2.0 branch)
Keywords: ffado mixer bus reconfiguration in progress Cc:
The device the bug applies to:

Description

If I launch two or more instances of ffado mixer under ffado 2.0 svn / Debian Squeeze (which is quite easily done if you have a shortcut set for it set to launch via single-click) a ffado-dbus-server process is launched for each mixer process and so ffado-mixer doesn't successfully start. You simply get the "Bus reconfiguration in progress" message and have to close all ffado mixer windows and do a:

killall ffado-dbus-server

Before you can successfully launch ffado mixer.

Apologies if this is actually a Debian (or more specifically AV Linux) bug but ideally ffado-dbus-server should prevent multiple instances of itself being launched to prevent this happening. This is when being used with a Saffire Pro 26.

Change History

04/07/12 05:14:31 changed by jwoithe

As of svn trunk r2117, multiple starts of ffado-mixer do not generally cause more than one ffado-dbus-server to start. However, if two ffado-mixer applications are started in quick succession (which may be the situation encountered by the original reporter) then I guess it's possible that they will both attempt to start ffado-dbus-server because both may fail to detect a running ffado-dbus-server during their startup.

I agree that ffado-dbus-server should try to prevent multiple instances running, but in the case where two are started in quick succession one can't rely on dbus for this functionality. We probably need to add a lock file or something, but then there's the potential issue of cleaning up stale locks after a crash or unclean shutdown. Will the cure be worse than the disease in this instance?

Another option would be the use of a PID file as a lock, and conclude it's invalid if the listed process isn't ffado-mixer. However, even this is not foolproof.

Similarly one could argue that ffado-mixer should do the same - prevent multiple copies running at the same time. Because there's no mechanism for updated device settings to be "pushed" to ffado-mixer, changes in one ffado-mixer won't propagate to any others. Therefore, even in the corner cases where running multiple ffado-mixers would be useful, it wouldn't really work out in practice.

How should we proceed here? Should we close this ticket and just accept that these issues exist? Or should we attempt a fix?

04/16/12 06:43:28 changed by jwoithe

  • status changed from new to closed.
  • resolution set to fixed.

Having thought about this some more, the easiest option at this stage is to address the high-level cause of this problem - the rapid starting of more than one ffado-mixer instance. Svn r2122 commits a change which uses a unix domain socket as a lock which ensures that only one ffado-mixer can run at once. Since the test for the lock is done before attempting to start ffado-dbus-server, it should now no longer be possible for two rapidly started ffado-mixer processes to each start a ffado-dbus-server. By using a domain socket we can be sure that the "lock" is automatically cleaned up when ffado-mixer exits - either cleanly or as a result of a crash.

With this change it is still possible to manually run more than one ffado-dbus-server process at once. However, ffado-dbus-server is not designed to be run directly by the user in this way, so I'm inclined to leave things at that for now. As the code stands now, it should not be possible for multiple ffado-dbus-server instances to be started when ffado-mixer and ffado-dbus-mixer is used as designed. If there is a corner case I have not considered or my analysis is wrong in some way please re-open this ticket.