Hi,

while I won't have time to attend the Telco, I guess, here would be the place to provide some feedback?

I just skimmed the paper, so please excuse any bullshit in my argumentation, so this is just a quick observation of potential design issues lurking:

1. why is the inconsistency in represening counts/sizes between audio_buffer and audio_device? size_t vs. int, naming of member functions.

2. in 6.5:
is the iterator return type of audio_device_list define somewhere else? if not, it should at least be a typedef in the list type and specify, that its  operator* returns an audio_device (or an optional<audio_device> to make code safer.)

3. why are the setter functions not noexcept? They return a bool to denote success. I consider the many bool returning functions a kind of design smell. Has anybody considered to employ enums for that? (I understand that often requires to negate logic). Also a type with getters and setters is always suspect for me, since it leaks abstractions. Would sample rate and bufffer size frames somehow be related and just a missing single abstraction, or other combinations?

4. There seem to be deeper portability issues with the implementation defined types leaking and providing setters for them. What kind of operations would be possible on such a type, how could it be set to a different value than one previously received in a portable way. Why not provide a strong type wrapper (e.g., for sample_rate_t and buffer_size_t) with defined operations instead, so that it is clear, what are supported. Are set/get really the right API, or is a "Change/AdjustBy" a better API. I do not know the domain, so that makes me unsure, but obtaining a value, doing arbitrary arithmetic, then setting a value seems not a good abstraction.

5. bool queries: is_running(), is_input(), supports_sample_type<T>(), ... -> it seems to me there is a state machine lurking may be, or at least a state space that the device can represent. I think this should be modeled more explicitly, it might provide insights to a better abstraction than a boolean sea.

6. 6.8: Why is audio_device_io not a struct. closing angle brackets are missing.

7. 7.1/7.3 the while(true); is ihmo UB. Could we make it while(device.has_unprocessed_io()); or similarly check the state of it.

Just my CHF 0.02 on potential design issues. May be I should have spoken up earlier, but I tried for 2D graphics, but it was just too big to start with. Audio seems smaller and more approachable.

Regards
Peter.

Roger Orr via SG13 wrote on 18.06.19 09:23:
Message
A reminder of this Thursday's SG13 telecon.
 
We currently have two revised papers to discuss:
 
P0267R9 (revised 2D graphics paper - previoulsy circulated)
P1386R2 (revised audio paper - a copy is attached)
 
If you have a paper relevant to SG13 in the pre-meeting mailing please let me know, and/or post it or a link to this list for ease of reference (since the pre meeting mailing may well not be out in time for Thursday)
 
Regards,
Roger.