-
Notifications
You must be signed in to change notification settings - Fork 171
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Missing points at the last buffer #55
Comments
I assume this is the change you are talking about:
With that change, the test suite fails with a segfault. |
Hmm... A quick fix is not a good fix, I guess. Or, was there anything I missed? Perhaps was I calling src_process a wrong way? That is possible because I had to do a lot of guesswork while using it. |
I am still unconvinced that there even is an issue. This is a widely used library, that has changed little in a decade and it has a comprehensive test suite. The tests and the example code in this repo show how to use |
@bjkwon I was having the same problem and it seems that you are supposed to call |
Yes, as @Ashymad says, you are supposed to keep calling The examples do this, for example |
To start off, thank you so much for the great tool, erikd!
But I have found an issue and, after some trials-and-errors, came up with a simple solution. I would like to share---
When src_process is called multiple times with a connected set of buffers, the last
half_filter_chan_len
points from the input buffer are not processed. In other words, you will lose these data points (which was 47 samples when I tried with SRC_SINC_MEDIUM_QUALITY, see below). This is because the while loop on line 375 in src_sinc.c breaks whenfilter->out_gen
equalsfilter->out_count
. Logically it makes sense, except that it should further generate output (half_filter_chan_len
points more) for the very last buffer, because the processing of the very first buffer was done forfilter->out_count
MINUShalf_filter_chan_len
.To resolve this issue, I am simply changing line 375 to
while (1)
and let the separate termination check do the work (lines 390 and 393). And I am making sure, in my application, to allocate the data_out buffer big enough to absorb this in addition to the expected output buffer size.The same logic should apply to other functions--
sinc_stereo_vari_process, sinc_quad_vari_process, sinc_hex_vari_process
, andsinc_multichan_vari_process
, but I'm not using them and I can't check this issue in these functions. I would let others do it. But this change works well for my application, auxlab, so I'm using my own hacked version of libsamplerate for auxlab for now (as of 3/20/2019).The easiest way to replicate the issue is the following:
This hack will get you all the output data, without missing the last 47 points.
Hope this helps.
The text was updated successfully, but these errors were encountered: