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@lists.isocpp.org> 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@lists.isocpp.org> wrote:

Hi again,

On 19 Jun 2019, at 15:55, Peter Sommerlad (CPP) <peter.cpp@sommerlad.ch> 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@lists.isocpp.org
http://lists.isocpp.org/mailman/listinfo.cgi/sg13


--
SG13 mailing list
SG13@lists.isocpp.org
http://lists.isocpp.org/mailman/listinfo.cgi/sg13