Change of behavior in AudioCVT & SDL_ConvertAudio from 2.0.5 to 2.0.6


#1

Hi guys,

I’m Cobrand, the current maintainer of the Rust-lang bindings for SDL2. Recently we’ve discovered that by upgrading SDL2 from 2.0.5 to 2.0.6, our test suite fails because the behavior of the SDL2 lib changed.

I just wanted to report the changes we’ve noticed for you to confirm whether or not this looks like a bug/regression. Note that this still happens with the stable version of 2.0.8

The Operating System doesn’t seem to be a factor, although I can say for 100% sure this “regression” happens on linux x86_64.

Here is the sample:

// compile with: gcc main.c -o app -lSDL2
// run with: ./app
#include <SDL2/SDL.h>
#include <stdio.h>

int test_audio_stuff() {
    SDL_AudioCVT cvt;
    SDL_BuildAudioCVT(&cvt, AUDIO_U8, 1, 48000, AUDIO_U8, 2, 48000);
    SDL_assert(cvt.needed); // obviously, this one is always needed.
    cvt.len = 256; // 256 mono u8 frames.
    cvt.buf = (Uint8 *) SDL_malloc(cvt.len * cvt.len_mult);

    for (int i = 0; i < 256; i++) {
        cvt.buf[i] = i;
    }
    SDL_ConvertAudio(&cvt);
    printf("Converted buffer has size of %d\n", cvt.len_cvt); 
    for (int i = 0; i < cvt.len_cvt; i++) {
        printf("%02d ", cvt.buf[i]);
    }
    printf("\n");

    printf("expected buffer:\n");
    for (int i = 0; i < cvt.len_cvt; i++) {
        printf("%02d ", i / 2);
    }
    printf("\n");
}

int main(int argc, char* args[]) {
    test_audio_stuff();
    return 0;
}

(My C is rusty, sorry about that)

This example has the simple goal to convert a U8-mono stream into a U8-stereo stream. Simple, right?

If the original stream goes like [0 1 2 3 4 5 6 7] we expect to see [0 0 1 1 2 2 3 3 4 4 5 5 6 6 7 7], right? Each byte gets simply duplicated once. Our test suite did exactly that but with 255 values: https://github.com/Rust-SDL2/rust-sdl2/blob/07723632dfa7a019ab4d3e153dc9b808337460fd/src/sdl2/audio.rs#L819-L835

However, it failed (the code above is the equivalent in C), here is what it outputs:

Converted buffer has size of 512
00 00 01 01 02 02 03 03 04 04 05 05 06 06 07 07 08 08 09 09 10 10 11 11 12 12 13 13 14 14 15 15 16 16 17 17 18 18 19 19 20 20 21 21 22 22 23 23 24 24 25 25 26 26 27 27 28 28 29 29 30 30 31 31 32 32 33 33 3434 35 35 36 36 37 37 38 38 39 39 40 40 41 41 42 42 43 43 44 44 45 45 46 46 47 47 48 48 49 49 50 50 51 51 52 52 53 53 54 54 55 55 56 56 57 57 58 58 59 59 60 60 61 61 62 62 63 63 64 64 64 64 65 65 66 66 67 6768 68 69 69 70 70 71 71 72 72 73 73 74 74 75 75 76 76 77 77 78 78 79 79 80 80 81 81 82 82 83 83 84 84 85 85 86 86 87 87 88 88 89 89 90 90 91 91 92 92 93 93 94 94 95 95 96 96 97 97 98 98 99 99 100 100 101 101 102 102 103 103 104 104 105 105 106 106 107 107 108 108 109 109 110 110 111 111 112 112 113 113 114 114 115 115 116 116 117 117 118 118 119 119 120 120 121 121 122 122 123 123 124 124 125 125 126 126 127 127 128 128 129 129 130 130 131 131 132 132 133 133 134 134 135 135 136 136 137 137 138 138 139 139 140 140 141 141 142 142 143 143 144 144 145 145 146 146 147 147 148 148 149 149 150 150 151 151 152 152 153 153 154 154 155 155 156 156 157 157 158 158 159 159 160 160 161 161 162 162 163 163 164 164 165 165 166 166 167 167 168 168 169 169 170 170 171 171 172 172 173 173 174 174 175 175 176 176 177 177 178 178 179179 180 180 181 181 182 182 183 183 184 184 185 185 186 186 187 187 188 188 189 189 190 190 190 190 191 191 192 192 193 193 194 194 195 195 196 196 197 197 198 198 199 199 200 200 201 201 202 202 203 203 204 204 205 205 206 206 207 207 208 208 209 209 210 210 211 211 212 212 213 213 214 214 215 215 216 216 217 217 218 218 219 219 220 220 221 221 222 222 223 223 224 224 225 225 226 226 227 227 228 228 229 229 230 230 231 231 232 232 233 233 234 234 235 235 236 236 237 237 238 238 239 239 240 240 241 241 242 242 243 243 244 244 245 245 246 246 247 247 248 248 249 249 250 250 251 251 252 252 253 253
expected buffer:
00 00 01 01 02 02 03 03 04 04 05 05 06 06 07 07 08 08 09 09 10 10 11 11 12 12 13 13 14 14 15 15 16 16 17 17 18 18 19 19 20 20 21 21 22 22 23 23 24 24 25 25 26 26 27 27 28 28 29 29 30 30 31 31 32 32 33 33 3434 35 35 36 36 37 37 38 38 39 39 40 40 41 41 42 42 43 43 44 44 45 45 46 46 47 47 48 48 49 49 50 50 51 51 52 52 53 53 54 54 55 55 56 56 57 57 58 58 59 59 60 60 61 61 62 62 63 63 64 64 65 65 66 66 67 67 68 6869 69 70 70 71 71 72 72 73 73 74 74 75 75 76 76 77 77 78 78 79 79 80 80 81 81 82 82 83 83 84 84 85 85 86 86 87 87 88 88 89 89 90 90 91 91 92 92 93 93 94 94 95 95 96 96 97 97 98 98 99 99 100 100 101 101 102 102 103 103 104 104 105 105 106 106 107 107 108 108 109 109 110 110 111 111 112 112 113 113 114 114 115 115 116 116 117 117 118 118 119 119 120 120 121 121 122 122 123 123 124 124 125 125 126 126 127 127 128128 129 129 130 130 131 131 132 132 133 133 134 134 135 135 136 136 137 137 138 138 139 139 140 140 141 141 142 142 143 143 144 144 145 145 146 146 147 147 148 148 149 149 150 150 151 151 152 152 153 153 154 154 155 155 156 156 157 157 158 158 159 159 160 160 161 161 162 162 163 163 164 164 165 165 166 166 167 167 168 168 169 169 170 170 171 171 172 172 173 173 174 174 175 175 176 176 177 177 178 178 179 179 180 180 181 181 182 182 183 183 184 184 185 185 186 186 187 187 188 188 189 189 190 190 191 191 192 192 193 193 194 194 195 195 196 196 197 197 198 198 199 199 200 200 201 201 202 202 203 203 204 204 205 205 206 206 207 207 208 208 209 209 210 210 211 211 212 212 213 213 214 214 215 215 216 216 217 217 218 218 219 219 220 220 221 221 222 222 223 223 224 224 225 225 226 226 227 227 228 228 229 229 230 230 231 231232 232 233 233 234 234 235 235 236 236 237 237 238 238 239 239 240 240 241 241 242 242 243 243 244 244 245 245 246 246 247 247 248 248 249 249 250 250 251 251 252 252 253 253 254 254 255 255

It’s quite hard to catch but in the first result the bytes “64” and “190” are duplicated one too many times each (being there 4 times instead of 2 times). As a result, we can see the buffers ends with 253 253 instead of 255 255.

This looks like nothing but I suspect this may cause very slight audio glitches that I think can be noticeable (since we have this issue 2 times for 256 bytes, we can only assume it’s going to be much worse for a buffer of a whole second or 48000 bytes…)

I’m almost certain this is a bug, but please feel free to correct me if I’m wrong in any way