-
Notifications
You must be signed in to change notification settings - Fork 465
Open
Labels
Description
The SupportedStreamConfigRange, SuportedStreamConfig and StreamConfig types make configuring streams in cpal far more complicated and unpleasant than it would need to be.
SupportedStreamConfigRange- range of sampling rates and buffer sizesSupportedStreamConfig- fixed sampling rate, range of buffer sizesStreamConfig- fixed sampling rate, fixed or 'default' buffer size
I'm not sure why there's even a need for SupportedStreamConfig, but the main point why I opened this issue is that the naively expected chain of Iterator<SupportedStreamConfigRange> -> SupportedStreamConfigRange -> SupportedStreamConfig -> StreamConfig is incomplete.
- I get the iterator, and filter it to get one or more candidates.
- Then on those, I call
try_with_sample_rateto get aSupportedStreamConfig. This is where the first problem is: bad documentation:/// Retrieve a [SupportedStreamConfig] with the given sample rate and buffer size.The signature of the method is(self, sample_rate: SampleRate), no buffer size I could specify. - Getting a
SupportedStreamConfig, I'd then like to narrow down the buffer size, as at least on Linux, most devices return with a buffer size range of between 1 and MAXINT32 or so. However, there is no method for doing this. As mentioned in Prototyping an API for getting the supported min and max buffersizes #401, theconfigmethod on this type just returns aStreamConfigwith aDefaultbuffersize setting.
So in the end, I'm still hand-assembling a StreamConfig.
I guess the first step would be to have a try_with_fixed_buffer_size method on SupportedStreamConfig. Then, if there's no good reason for it, it might be meaningful to roll SupportedStreamConfigRange and SupportedStreamConfig into a single type?
Tenzenmaster, belohnung, playdohface and tomoyanonymous