search

koord-live / KoordASIO

A user-friendly universal ASIO driver for use with any Windows installation. Supports WASAPI (shared and exclusive) and includes config GUI.
https://koord.live
Other
78 stars 5 forks source link

Support ASIO config Reset (?) #9

Open danryu opened 1 year ago

danryu commented 1 year ago

Use Case:

Currently with Koord app (or Jamulus), if KoordASIO configuration is changed, the KoordASIO driver has to be "manually" released and loaded again in order to reflect the configuration change.

When changing KoordASIO toml configuration, this can be seen in the logs:

9037200:2023-02-06T15:19:25.9212439+02:00 21012 18408 Issuing reset request due to config change
9037203:2023-02-06T15:19:25.9213436+02:00 21012 18408 Reset request failed: reset requests are not supported

Not sure if this is a failure with the ASIO host, or with KoordASIO.

dechamps commented 1 year ago

This is an ASIO host issue. The ASIO driver is telling the ASIO host that it would like to be reloaded, but the ASIO host does not support that kind of request (specifically it does not support the kAsioResetRequest selector on the asioMessage callback), and so nothing happens.

Ideally, the ASIO host should support this request and diligently reload the driver in response. Unfortunately, in my experience many ASIO hosts do not support that request, or they support it but not in the most user-friendly way (e.g. they will show a "please reload the driver" message to the user instead of doing it automatically/transparently).

One way to improve on this on the driver side could be to implement a new mechanism in the driver whereby it would try to apply the new configuration "in place" while the stream is running (e.g. by closing and re-opening a PortAudio stream behind the scenes) instead of relying on the host to reload the driver. Obviously there would be quite a few difficulties in doing that: many configuration changes simply cannot be applied that way because they require cooperation from the ASIO host (e.g. different buffer size, different channel count, different sample types, different available sample rates), and it would disrupt callback timing.

danryu commented 1 year ago

@dechamps thanks for pre-empting my question!

I suspected this would have to be resolved host-side. Currently in the Koord app (which has KoordASIO integrated as the "Built-in" driver option) I have to jump through some hoops with each config change - effectively a full unload and reload. Once I handled the corner cases (failover, previous ASIO config invalid, broken config file) it is actually working fine now. https://github.com/koord-live/koord-app/blob/dev/src/sound/asio/sound.cpp#L85-L98

specifically it does not support the kAsioResetRequest selector on the asioMessage callback), and so nothing happens.

I guess I can try and implement the same behavior in this callback, to align with the standard approach.

One way to improve on this on the driver side could be to implement a new mechanism in the driver whereby it would try to apply the new configuration "in place" while the stream is running

The shortcomings you mention make this a no-go IMO. ASIO hosts are the responsible party in this case :)

dechamps commented 1 year ago

Once I handled the corner cases (failover, previous ASIO config invalid, broken config file)

To be clear, the driver will not trigger a reset request if a valid config file is replaced by a broken one:

https://github.com/koord-live/KoordASIO/blob/6bb099cf6b9cfe71cca6d83cfcb159ae706156b8/src/flexasio/FlexASIO/config.cpp#L315-L318

Though obviously this only covers the most basic kinds of "broken", e.g. config file syntax errors.

danryu commented 1 year ago

Though obviously this only covers the most basic kinds of "broken", e.g. config file syntax errors.

Ok this makes sense. In my case (with Koord app) I have to do higher-level validation (number of inputs+outputs, sampling freq) for the ASIO configuration to be successfully loaded. (Somehow I would end up with device="" on an initialization round and that would trigger the invalidation - etc) What's particularly nice about having KoordASIO integrated now, is that I don't have to worry about the "no ASIO drivers installed" case. I always have a configurable driver on hand that's pretty much guaranteed to load on the available hardware. Also potentially much simpler for users.