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.
>
>
>