| 1 | | Ok, I did re-check, and I can confirm I get srcSampleCount == destSampleCount == 2048, which leads to the optimization path being taken, and no resampling at all. Unless there are multiple mixers used and this one only does the float to int conversion with another one changing the sample rate (using another function like float to float). |
| | 1 | Ok, I found what I was doing wring. There are actually two mixer instances, one doing the sample rate conversion and anoter one converting the format. This is suboptimal, but ok, it can work. |
| | 2 | |
| | 3 | Now, here is what I see : |
| | 4 | * The media kit size the resampling buffer to be 1/50th of a second, that is, 960 samples at 44800Hz. |
| | 5 | * It seems that sometime we get buffer of different sizes, but that may be caused by the debug output making things too slow. I saw some calls to resample with as low as 17 samples. In this case the computed delta is 1.13 instead of 1.08, so the interpolation isn't stable. |
| | 6 | |
| | 7 | I fail to see the purpose of having two resamplers. But more importantly, I need to know the sample rate of input and output when constructing a filtering resampler, to precompute some tables and make the filter lighter in cpu use (and thus suitable for ral time resampling). With the way mixer nodes are instanciated, this is not possible. I can't know the input sample rate when the mixer is created, and have to guess it when I start receiving samples. What if an application decides to send longer frames (like 1second of audio at a time) ? |
