Bug 6385 - Better error reporting for AudioToolbox API
Summary: Better error reporting for AudioToolbox API
Status: RESOLVED FIXED
Alias: None
Product: iOS
Classification: Xamarin
Component: XI runtime ()
Version: 5.2
Hardware: PC Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Marek Safar
URL:
Depends on:
Blocks:
 
Reported: 2012-08-03 19:29 UTC by adam.lickel
Modified: 2013-04-04 13:16 UTC (History)
3 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

Description adam.lickel 2012-08-03 19:29:38 UTC
Calling this method in the first callback of AudioFileStream.PacketDecoded (which means it should be populated).
I'm getting a value of 0.

As far as I know this is a regression in v5.2.12
Comment 1 Rolf Bjarne Kvinge [MSFT] 2012-10-22 09:00:11 UTC
I do not believe this to be a bug in MonoTouch, it's rather how iOS works.

With this test code I was able to get an error code (1970170687= kAudioFileStreamError_ValueUnknown = The property value is not present in this file before the audio data.)

[System.Runtime.InteropServices.DllImport (MonoTouch.Constants.AudioToolboxLibrary)]
extern static int AudioFileStreamGetProperty (IntPtr audioFile, int property, ref int dataSize, out long outdata);

long res;
int size = sizeof (long);
IntPtr h = (IntPtr) typeof (AudioFileStream).GetField ("handle", System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.NonPublic).GetValue (file_stream);
int rv = AudioFileStreamGetProperty (h, 0x70636e74, ref size, out res);
Console.WriteLine ("rv: {0} res: {1}", rv, res);
Comment 2 Rolf Bjarne Kvinge [MSFT] 2012-10-22 09:01:32 UTC
However it should be easier to get this kind of information without resorting to ugly hacks like this one.

Marek, can you have a look at providing better ways of getting any errors out of this API?
Comment 3 Miguel de Icaza [MSFT] 2012-11-12 18:13:46 UTC
I do not want to introduce exceptions in this case, since this could potentially break code that assumed that things were fine before.

What if we keep a "LastError", similar to "errno" on Unix?

Miguel
Comment 4 Rolf Bjarne Kvinge [MSFT] 2012-11-12 18:16:44 UTC
That doesn't sound very discoverable. I was thinking more in the lines of overloads with an out parameter.
Comment 5 Miguel de Icaza [MSFT] 2012-11-13 12:49:34 UTC
We can document these on each property.

Because we would now have:

int Foo { get; set; }

int GetFoo (out ret);
int SetFoo (out ret)

Which is just ugly.
Comment 6 Marek Safar 2012-11-14 09:47:21 UTC
Populating LastError for some method and throwing exception is others in same class is not really great. I'd vote for exception even if it can break probably broken existing code instead of introducing yet another way how to check for error to our bindings.
Comment 7 Miguel de Icaza [MSFT] 2012-11-14 11:40:39 UTC
I am not suggesting that we do both (exceptions + last error), I was merely exploring the options and basically not wanting to do the excpetion.

My recommendation is to go with LastError, to avoid breaking existing code.   

The reason to not break code is that it is possible that reading/setting a property had no negative effect, or any negative effect in some code paths, and now we would be breaking the code.   And I am very much against that.

I am not really ready to make a bunch of our customers unhappy.   

I would be willing to add some logging to notify the users "Hey, you are using this wrong", but not more than that.
Comment 8 Marek Safar 2013-04-04 13:16:26 UTC
Fixed in master