30 Mar
2019
30 Mar
'19
6:34 a.m.
On Sat, March 30, 2019 13:25, Fons Adriaensen wrote:
On Sat, Mar 30, 2019 at 11:26:24AM +0100, Thomas Brand
wrote:
Good idea, instead of shutting down, the server would just go into
freewheeling (which clients should be able to handle transparently) until
a new backend is attached.
If server operation would be separated from backend (freely attach /
dettach), this would open up new possibilities.
On a related note, I thought about jack to fall back to dummy interface
every time a normal start isn't possible. We could guarantee that jack can
always be started, and if backends can be freely swapped, this wouldn't be
a problem (just attach one later). Just thinking out loud.
Greetings
Thomas
I think it's not that simple. If jack looses
its backend, there's
nothing to connect to, no clock etc. Even if jack can take care of the
time where no backend is available, if a new backend is attached, it
might have a different SR or different buffersize.
Actually I think something could be done without too much complexity.
* When Jack detects that a backend goes away, it switches to a 'dummy'
one with the same sample rate, buffer size, and number of channels.
Basically this is the same as freewheeling, except that waiting for
a timer would be inserted in between cycles.
* When the backend is available again, there is a single API call
that re-initiliases it with the existing parameters. Once this is done,
Jack switches back.
Apart from signalling the events (again similar to freewheeling) this
could be transparent to clients.