[Libav-user] Converting audio sample buffer format

["René J.V. Bertin"]

On Feb 25, 2013, at 18:19, Brad O'Hearne wrote:

> All of my code is running in the debugger, but I'm linking to the FFmpeg libraries built on the command line. In other words, I can step to the library calls themselves, but not inside, and the call is completely crashing the app, with no more information than an EXC_ARITHMETIC (presumably divide by 0) error. 

If you build with debug info (either with --enable-debug=1 passed to configure, or by ensuring that -g is part of your CFLAGS) you ought to be able to step into the library functions.

> I had hoped to avoid debugging through FFmpeg source for a few reasons: 
> 
> - I suspect it is going to be quite a job to pull all of the source into my project without causing the compiler to ball up in the corner and weep...think there may be a time consuming project configuration task there, which is going to be a similar experience of wandering about in the dark for a few days. 

No need for that, as noted above. All you need to do is drag the FFmpeg folder (the source folder, not your build directory) into your project and make sure the code is not added to any of your projects. Xcode will index the code, and its gdb interface will use that information to give you access to the source code for the library functions.
NB: gcc and clang accept -g with -O{,1,2,3,s}.

> - After manually reading through the source code path inside the swr-convert call, it seemed likely that even if I found the line which resulted in a divide by zero, I'm still not sure I'd even know what to do with it, or what the expectation of the prior code was (other than, of course, divide by zero). 

Of course, but for that you ought to find people in the know on here.

> - swr_convert is crashing -- not returning an error, mind you, but outright crashing. 

No answer to your question, but once you have your debugger environment set up correctly you don't even have to step through until you find the error. That is, if your bug is not a Heisenbug, i.e. one that disappears as soon as you squint at it too directly ;)

Something else you can do just to exclude side-effects of things like stack corruption: run your code with the malloc protection active (see man malloc) and through valgrind to see if the crash occurs elsewhere or if you get other messages.
Another option would be to run the analyser on your code (supposing Xcode still has that option).

> 
> Does this scan, or is it not a possibility? 

The conversion is indeed likely to contain a division. If round-off doesn't work exactly right (**) and one of swr_convert's siblings doesn't check against zero division, you could indeed end up doing that.

It should be easy enough to see if your input is signed or not. Look at a recorded white noise signal. If the average of your input buffer is (approx.) 0, you have signed data; if it's non zero with a range between 0 and (probably) twice the mean you have unsigned samples.

**) don't x86 CPUs have multiple settings that control the way calculations are rounded off, or am I confounding with instruction variants that round off differently?

R.