alsa: simplify probing for default latency#1152
Conversation
Use a method that is less prone to failure. Also change GropeDevice() to ProbeDeviceDefaults(). Fixes #1145
| } | ||
|
|
||
| { | ||
| /* It happens that this call fails because the device is busy */ |
There was a problem hiding this comment.
Does this comment explain a bug?
Or is it expected behavior?
| double defaultSr = devInfo->baseDeviceInfo.defaultSampleRate; | ||
| unsigned int approximateSampleRate = 0; | ||
| const int kLowBufferFrames = 512; | ||
| const int kHighBufferFrames = 2048; |
There was a problem hiding this comment.
Please check style guide. k prefix is not our style for constants.
| *defaultHighLatency = (double) (alsaBufferFrames - alsaPeriodFrames) / defaultSr; | ||
| ret = alsa_snd_pcm_hw_params_get_buffer_size_min( hwParams, &lowBufferFrames ); | ||
| if (ret) { | ||
| printf( "%s: alsa_snd_pcm_hw_params_get_buffer_size_min() returned %d !\n", __FUNCTION__, ret ); |
There was a problem hiding this comment.
I would make it clear that this is the failure case. "... failed, returnd %d"
RossBencina
left a comment
RossBencina
left a comment
There was a problem hiding this comment.
I notice that you've removed setting the sample rate. I wonder whether you get different buffer bounds back from alsa if you set the sample rate first, as in the old code. The function do query the current state of the configuration space:
https://www.alsa-project.org/alsa-doc/alsa-lib/pcm_2pcm_8c.html#a3caf61ab086028067b602d48182df708
Yes. The old code had to reset the sample rate any time it tried to set buffer or period sizes. |
2 participants
Use a method that is less prone to failure.
Also change GropeDevice() to ProbeDeviceDefaults().
Fixes #1145