Hi everyone,

I've been implementing an ASIO backend for Windows. I'd just like to
comment that a device settings negotiation API should also consider which
channels are used after connection. ASIO devices are often full-duplex with
multiple inputs & outputs - we don't want to copy data over unused
channels. We also want to allow clients to opt-in to full-duplex mode (not
available on my current PR)

So far, the ASIO backend takes the approach of converting all samples
to/from float types. It would be nice to expose the native ASIO type (which
is driver-dependent) so that the user can choose to connect optimally.

Re. Peter's comments about the implicit state machine: My gut feeling is
that exposing the state machine explicitly would scarifice the simplicity
of the 'Hello, World" examples and become more of a barrier-to-entry for
general users. IMHO, the audio_device should act more like a media player
(or recorder) object, i.e. a layer of abstraction higher than the internal
state machine. This would fit with standardizing existing practices too.

Timur, thanks for publishing P1386R2! I can implement the stop/start
callbacks correctly now :)

Cheers,
Andy

On Wed, 19 Jun 2019 at 17:19, Peter Sommerlad (CPP) via SG13 <
sg13_at_[hidden]> wrote:

> Will a configuration change automatically stop the device, or must it be
> stopped before the configuration change happens?
>
> In the latter it looks to me like "moving" the handle between my suggested
> "configurator" and "proesseor" objects. who both provide different APIs.
>
> Regards Peter
>
> Timur Doumler wrote on 19.06.19 17:22:
>
> Oh, and there should also be an arrow from “configuring” to “doing
> nothing”, because obviously the device can become unavailable while you are
> in the configuring state.
>
> Cheers,
> Timur
>
> On 19 Jun 2019, at 18:13, Timur Doumler via SG13 <sg13_at_[hidden]>
> wrote:
>
> Hi again,
>
> On 19 Jun 2019, at 15:55, Peter Sommerlad (CPP) <peter.cpp_at_[hidden]>
> wrote:
> Drawing the actual state diagram of the lifetime of a system audio device
> can help to figure out where to make the cut and figure out, if there are
> even more things lurking, such as the interdependency of sample rate and
> buffer size.
>
>
> Here’s my very crude attempt at a state machine diagram for the audio
> device.
>
> Cheers,
> Timur
>
> <audio_device_diagram.png>
> --
> SG13 mailing list
> SG13_at_[hidden]
> http://lists.isocpp.org/mailman/listinfo.cgi/sg13
>
>
>
> --
> SG13 mailing list
> SG13_at_[hidden]
> http://lists.isocpp.org/mailman/listinfo.cgi/sg13
>