You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now when receiving an BackendSpecificError you can either:
close the stream on the first BackendSpecificError since you have no idea if its critical, but that means an underrun is not recoverable. You could try accepting a few errors and only then aborting but this is still very brittle.
continue in the hope that error will clear, probably correct behavior for underruns.
This would return None if it is not known whether the error is recoverable or not. The error struct would stay the same, simply a description as String. The function would work by searching for known error messages, such as ALSA underruns in the description.
Alternative
Parse all errors as they occur, do away with BackendSpecificError making a separate enum for each backend. Disadvantage lots of work, parsing always happens instead of being a choice for the user. Advantage no more need to allocate a String for every error. We would probably still need the String fallback in case we can not parse/recognize the error. What this means for performance, no idea.
The text was updated successfully, but these errors were encountered:
Right now when receiving an
BackendSpecificError
you can either:BackendSpecificError
since you have no idea if its critical, but that means an underrun is not recoverable. You could try accepting a few errors and only then aborting but this is still very brittle.Possible backward compatible solution:
This would return
None
if it is not known whether the error is recoverable or not. The error struct would stay the same, simply a description as String. The function would work by searching for known error messages, such as ALSA underruns in the description.Alternative
Parse all errors as they occur, do away with BackendSpecificError making a separate enum for each backend. Disadvantage lots of work, parsing always happens instead of being a choice for the user. Advantage no more need to allocate a String for every error. We would probably still need the String fallback in case we can not parse/recognize the error. What this means for performance, no idea.
The text was updated successfully, but these errors were encountered: