Bug 24364 - AVAudioRecorder when file URL is fake lead to sideeffects
Summary: AVAudioRecorder when file URL is fake lead to sideeffects
Alias: None
Product: iOS
Classification: Xamarin
Component: Xamarin.iOS.dll ()
Version: XI 8.4.0
Hardware: Macintosh Mac OS
: Normal normal
Target Milestone: Untriaged
Assignee: Paola Villarreal
Depends on:
Reported: 2014-11-08 17:54 UTC by alex.andronov
Modified: 2014-12-13 09:14 UTC (History)
3 users (show)

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

the ViewController starts recording voice in ViewDidLoad and write power to console (1.69 KB, application/octet-stream)
2014-11-08 17:54 UTC, alex.andronov
same example in ObjectiveC (1.75 KB, application/octet-stream)
2014-11-28 15:41 UTC, alex.andronov

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:

Description alex.andronov 2014-11-08 17:54:51 UTC
Created attachment 8669 [details]
the ViewController starts recording voice in ViewDidLoad and write power to console

- Trying to record voice and measure the power
- Create AVAudioRecorder with fake URL (like NSUrl.FromFilename (@"/dev/fake.wav");
- Set a category for AudioSession as Record or PlayAndRecord
- Start Recording and measure power
- AveragePower(0) return -120 or -160, no other values

See attachment with detailed code.

The problem is that Xamarin.iOS is not able to create a file with this URL and it doesn't raise any exceptions with explanation. If I change URL to:

var path = Environment.GetFolderPath (Environment.SpecialFolder.MyDocuments);
var filePath = Path.Combine(path, "file.wav");
var url = NSUrl.FromFilename (filePath);

it will work without any problems and I will be able to measure the power and save my recorder sound.

At the same time the similar functionality in ObjectiveC with such fake file will work without any problems and I will be able to measure the power.

It is up to you to decide if it is a bug or not. Of course if we are talking not only about measuring power but also about saving the recorder content, I suggest to fail with exception saying "Unable to save recorder bytes to file" or something like this.
Comment 1 Ram Chandra 2014-11-10 08:56:30 UTC
I can reproduce the reported behavior. I have observed that XS.iOS doesn't raise any exception / error when user try to create the any file in fake url . I also observed if I enter the fake url, XS shows the "AveragePower(0)" in -120 but if we give the correct url it shows "AveragePower(0)" with different values. I’ll need confirmation from the developer if this is a bug. 

Leaving as NEW for now.

Screencast:  http://www.screencast.com/t/RUWwKGmoFmPe

Environment Info:

=== Xamarin Studio ===

Version 5.5.3 (build 6)
Installation UUID: 6ea47b0d-1852-4aaf-808d-373ff0a5002b
	Mono 3.10.0 ((detached/e204655)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 310000023

=== Apple Developer Tools ===

Xcode 6.1 (6604)
Build 6A1052d

=== Xamarin.Mac ===

Version: (Trial Edition)

=== Xamarin.Android ===

Version: 4.18.0 (Trial Edition)
Android SDK: /Users/jatin66/Desktop/Backup/android-sdk-macosx
	Supported Android versions:
		1.6    (API level 4)
		2.1    (API level 7)
		2.2    (API level 8)
		2.3    (API level 10)
		3.0    (API level 11)
		3.1    (API level 12)
		3.2    (API level 13)
		4.0    (API level 14)
		4.0.3  (API level 15)
		4.1    (API level 16)
		4.2    (API level 17)
		4.3    (API level 18)
		4.4    (API level 19)
		4.4.87 (API level 20)
Java SDK: /usr
java version "1.7.0_65"
Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)

=== Xamarin.iOS ===

Version: (Trial Edition)
Hash: 08968c4
Build date: 2014-10-20 21:48:06-0400

=== Build Information ===

Release ID: 505030006
Git revision: fbe3e9453daf6a3bb9a9709ed22bec35f7c9056b
Build date: 2014-10-23 13:08:38-04
Xamarin addins: e44add2b39de4dd57c0742bb2e620dfad84c64c6

=== Operating System ===

Mac OS X 10.10.0
Darwin Jatin66s-iMac.local 14.0.0 Darwin Kernel Version 14.0.0
    Fri Sep 19 00:26:44 PDT 2014
    root:xnu-2782.1.97~2/RELEASE_X86_64 x86_64
Comment 2 Paola Villarreal 2014-11-28 13:36:14 UTC
Not sure yet if this is a bug or intended behaviour. An ObjectiveC would be interesting to test with.
Comment 3 alex.andronov 2014-11-28 15:41:33 UTC
Created attachment 8906 [details]
same example in ObjectiveC
Comment 4 alex.andronov 2014-11-28 15:41:54 UTC
added the same logic in Objective C
Comment 5 Paola Villarreal 2014-12-05 16:58:20 UTC
Yup, we have a bug. Will keep you posted here. 

Thank you.
Comment 6 Paola Villarreal 2014-12-05 20:29:25 UTC

On this gist 

You'll see the same issue occurs on both Xamarin.iOS and Objective C BUT the difference, and where the bug in Xamarin.iOS resides is that we are not setting the out NSError error to something other than null. 

On Objective C, this means that you return from the method because the error is not null ("Ups, could not create recorder"). On Xamarin.iOS, even if you add if (error == null) it won't be true. 

Changing status to IN PROGRESS.

 (thank you very much for posting the Objective C code, I meant that I was going to program an objc equivalent sample, not for you to post one)
Comment 7 Paola Villarreal 2014-12-11 20:46:25 UTC
This issue is fixed in 27d82ca94cdba2e5e64e3030c758913853900239.
QA: Unit tests were added in master/74b06f3485689c0b8d445e708a67cb2ddfac600a. 

The actual (incorrect) behaviour is that you can create a "valid" (as in not null) instance of AVAudioRecorder while having an invalid (as in, don't have write permissions) NSUrl Filename. We also were not 'out'ing the NSError so you could never check if anything went wrong.

The corrected behaviour now is: we now out the NSError and, if the AVAudioRecorder could not be instantiated it will be null.

Workaround in the meantime: check for write permissions of the file used in the NSUrl.
Comment 8 alex.andronov 2014-12-13 09:14:12 UTC
Cool, thanks for the fix :)