In fact, we did consider this kind of split before, where the device info/settings and the actual device (that does processing) are two separate classes.

We initially decided against that design because it makes user code more complicated: they would have to deal with more classes, instantiate more objects, and write more setup boilerplate.

Sounds like we should revisit that decision?

Cheers,
Timur

> On 19 Jun 2019, at 16:22, Timur Doumler via SG13 <sg13_at_[hidden]> wrote:
>
> Hi Peter,
>
> Quick reply: those are all great ideas that should be part of an updated design for a post-Cologne R3. Thank you!
>
> Will you be in Cologne so we can discuss all of that in person? There is a SG13 session scheduled for this paper.
>
> Cheers,
> Timur
>
>> On 19 Jun 2019, at 15:55, Peter Sommerlad (CPP) <peter.cpp_at_[hidden]> wrote:
>>
>> Hi Timur
>>
>> Timur Doumler wrote on 18.06.19 16:29:
>>>>
>>>> 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.
>>>
>>> See above. And no, change/adjustBy is not an appropriate API here. The way you set up audio devices is like this:
>>>
>>> - you acquire a handle to it
>>> - you negotiate what settings you can use
>>> - then you “start” the device, at which time it starts asynchronously processing stuff. it’s “running” now.
>>> - you can’t change any settings anymore on a “running” device. To do that, it has to be stopped and restarted.
>>>
>>>>
>>
>> This seems to be a stateful interface. While that is typical, I wonder if this must be implemented in a single type. Why not split the C++ part in a preparation type that does all the negotiation and then acts as a factory for the device that operates. If both use the same native handle, you can make the
>>
>> audio_processing_device getMeTheRealAudioThing() && ;
>>
>> a rvalue-ref qualified member to denote that the "AudioDeviceConfigurator" is no longer useful, because it passed out its handle and the
>>
>> So there are two things lurking in audio_device:
>>
>> 1. audio_device_configurator
>> 2. audio_processing_device
>>
>> Where the roughly first half of the member functions are part of the audio_device_configurator and the second half part of the audio_processing_device.
>>
>> You should not carry on the problems of a stateful underlying system API to your users. Clearly make the distinction.
>>
>> 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. May be that forms actually a combined abstraction (audio_performance_params?). Then something like audio_device_configurator::canHandle(audio_performance_params) can be used to allow to check before trying to set parameters and then one can guarantee (modulo races) that the combination works. With such an abstraction, one might even be giving a "best effort" mechanism, e.g. if I ask for 7.1 channels I get mono 9.6kbit sampling on my radio clock on the nightstand instead.
>>
>> Regards
>> Peter.
> --
> SG13 mailing list
> SG13_at_[hidden]
> http://lists.isocpp.org/mailman/listinfo.cgi/sg13