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
this is not about any wrong behaviour I would have noticed, but something that puzzled me when reading the code.
At https://github.com/go-audio/wav/blob/v1.1.0/decoder.go#L318 , since we're not returning nil, and we are returning m, and not explicitly 0, I assume that the call to Read above, could have partially succeeded until we hit the EOF, right?
If not, and if m is always 0 here, then you can forget about this issue (except I would explicitly return 0 to make it clear).
But if yes, then it means there possibly indeed is some data in tmpBuf at this point, right? And if yes, then I'm wondering why we are not copying the data from tmpBuf into buf.Data ? Shouldn't buf.Data always be populated as soon as m >= 0 is returned?
The text was updated successfully, but these errors were encountered:
Hey,
this is not about any wrong behaviour I would have noticed, but something that puzzled me when reading the code.
At https://github.com/go-audio/wav/blob/v1.1.0/decoder.go#L318 , since we're not returning nil, and we are returning m, and not explicitly 0, I assume that the call to Read above, could have partially succeeded until we hit the EOF, right?
If not, and if m is always 0 here, then you can forget about this issue (except I would explicitly return 0 to make it clear).
But if yes, then it means there possibly indeed is some data in tmpBuf at this point, right? And if yes, then I'm wondering why we are not copying the data from tmpBuf into buf.Data ? Shouldn't buf.Data always be populated as soon as m >= 0 is returned?
The text was updated successfully, but these errors were encountered: