Finch Audio Engine not opening default OpenAL device - iphone

I have an abstract class that initializes Finch to the global variable Finch *engine in the awakeFromNib method as follows:
engine = [[Finch alloc] init];
None of the abstract class's subclasses override the method. However, whenever I try my program, Finch prints "Finch: Could not open default OpenAL device." in the debugger. Why can't Finch get the default OpenAL device? As far as I can tell I'm doing everything as shown in their code example.

I just came across the same problem. For me, it was caused by instantiating a Finch object in more than one view controller. For some reason the second one seemed to cancel the first one out and I got that error message whenever I tried to play a sound.
To solve it, I simply created one Finch object in the App Delegate and now it's working perfectly throughout the whole app.
Hope this helps :)

Warning, if you are allocating multiple Finch classes:
In FISoundEngine, the dealloc method calls closeAudioDevice. This closes the OpenAL audio device.
And as you probably know, only one OpenAL device exists in your entire app!
So, that means you can only have one engine (and one factory) for your entire app,
or you will be closing the device in places where it should stay open.
Whether this is a design flaw, I don't know. I suggested that Finch be turned into
a singleton class, but my idea was rejected by the author.

Related

Aspect Oriented Programming in Objective-C for iPhone

Could anyone help me first when I can use AOP, and what is it exactly in an iphone programming.
I need to access to the app project source code and call some of the functions and be notified their views loaded from outside like a library.
I found these so far, but looks very complicated to follow. Some doesnt build or the source code removed.
https://github.com/ndcube/AOP-for-Objective-C
https://github.com/moszi/AOP-in-Objective-C
ACAspect on cocoadev
If you have a specific view in a view controller and want to be notified when it is loaded, you can register for a KVO notification when that instance variable (the outlet) changes.
You'll want to read up on Key Value Observing in Cocoa. There are several methods you will need to learn how to use.
Do a search on "Introduction to Key-Value Observing Programming Guide" in the XCode docs and read that section.
Make sure you balance each call to addObserver:forKeyPath:options:context: with a call to removeObserver:forKeyPath:, or your app may crash after the observing object is deallocated.

Best scenario to avoid memory leaks on iOS

I'm building an application that reads rss files something like Bing or Pulse, so I've built a class (UIViewController) that shows each individual entry in the feed and a class that contains that list of entries and another class that shows all the feeds at once, and I've not used any xib files so I've implemented a method in each class that gets called after each rotation to reset the frames of the views inside that class. But I'm facing a problem in the memory especially when calling that method when a rotation happens knowing that it just assigns a CGRect to each frame in the view.
So could you please help me to avoid this problem or suggest a different way to avoid it, and am I right about not using xib files or should I use them when ever I can and set the rotation thing inside them (using the auto resizing mask).
And if there is some complex free example like those applications, could any body point me to it.
Any help would be greatly appreciated,
and thanks in advance...
First, there is no reason to avoid nib files when they are useful to you. They are often useful. There is no reason to use nib files when they are not useful to you. If you have complex layout, they are definitely very useful. Whether to use them or not, however, is a personal choice based on the particular application. As a beginner, I would recommend using them and getting comfortable with them, and particularly relying on the Xcode templates to set them up correctly.
Nib files aren't your issue, one way or another here. You're leaking memory, and you need to investigate why. First, run the static analyzer to make sure there are no obvious errors. Then run your app under Instruments (Leaks) and look for large leaks. Then run your app under Instruments (Allocations) and look for what's eating the most memory. That should point you to your error.
The most likely cause, without any insight into your code, is that you are misusing ivars. Make sure that you access your ivars through accessors (except in init, dealloc and in the accessors). Directly accessing your ivars is the #1 cause of memory problems in iOS.
Release the objects properly which has been allocated and defined globally. Do not release the object of your UIViewController when it is active. Most of the leakage problems occur by releasing the object of the UIViewController before it reaches out of scope.

Using FMOD in multiple classes (iOS)

I am developing an iOS app where I am recording sound from the devices mic, saving it to a wav, then it needs to be accessed and played from a different view controller. As I understand, a FMOD::System object can only be defined in one view controller.
What would be the best way to access FMOD in more than one view controller?
I have tried using a Singleton class, however with objective-c's lack of class (non-instance) variables, I am not sure how declare the FMOD::System variable.
Has anyone successfully implemented what I am trying to do? Any help appreciated!
Thanks
I ended up making a singleton class and got it working.
If anyone would like help doing the same just ask.

AudioStreamer appDelegate

I have two things concerning AudioStreamer and i hope I'm getting some clues here:
1. I have set up a UITabBarController and in my Appdelegate is a AudioStreamer-Object. Two views refer to the appDelegate.streamer. It it looks like that im getting two sessions when i release and alloc it new. I get two running audiosession.
2. I use a UITableView to play out of this list. in the didSelectRowAtIndexPath-method I initialize with a URL. when the user taps with a fast double, or tripple-click. the audiosession will get startet three times. although i'm using a bool to prevent that. so my dirty solution is to set the system sleeping for a second. it is ugly because the screen freezes for a sec.
Thankfull for some hints
Simon
In terms of your problems, it sounds like you should implement your AudioSteamer as a singleton, as this will prevent multiple instances from being created and provide a single point to control playback (i.e.: prevent multiple taps from triggering multiple playbacks).
For more information on how to create a singleton class, see the "Creating a Singleton Instance" section within Apple's Cocoa Fundamentals Guide.
for 2nd point. It is a bug of AudioStreamer class. Also this has been solved and code is put up on gitHub see link. also if this does not seems working then you can go to the pause method and add more states as below
-(void)pause
{
if (state==AS_PLAYING || state==AS_BUFFERING || state==AS_WAITING_FOR_DATA)
{
//rest code goes same....
}
// rest code goes same....
}
this solved my same problem. Hope this will help you also...

How do I see every method called when I run my application in the iPhone Simulator?

I would really like to see every method, delegate, notification, etc. which is called / sent while I run my app in the iPhone Simulator. I thought the right place for this would be in the debugger, but I can't find the right setting.
My target is to see all that is happening in the background while I, for example, add a row to a UITableView or push the 'back'-button from my UINavigationController.
This would be a big help to figure out what delegate to use when something in the app is happening or when the user is pushing a button, changing a view, etc.
Is it possible to get this information?
You can log out everything that is happening when your application is running using DTrace, a framework that lets you probe the inner workings of anything running on a modern Mac. We don't yet have DTrace on iOS, but it will work while you're running within the Simulator.
I describe the fundamentals of DTrace in this article for MacResearch, then provide an example of a custom instrument you can build in Instruments using DTrace near the end of this article. That instrument logs out all methods called on all objects (even internal system ones) from the moment your application starts until it hits the end of -applicationDidFinishLaunching:.
To simplify this, you can simply create a custom instrument using the Instrument | Build New Instrument menu item in instruments. Set up one of the probe descriptors to look like the following:
only ignore the isInApplicationStart and timestamp logging options. A simple probe responding to any Objective-C method in any class will log all of those messages to the Instruments console, which sounds like what you want for your debugging.
Assuming you're sure you want absolutely everything...
Breakpoint objc_msgSend and objc_msgSend_stret. Almost all method calls use those two functions (mumble mumble IMP-cacheing).
Okay, now your app drops into the debugger all the time. So click the auto-continue box.
But now you don't see very much happening, so edit the breakpoints and add the command "bt" to get a backtrace.
Drown in debug spam.
This won't catch other C functions, of course.
If you just want to catch notifications, you can do something like this (much less spammy):
+(void)load
{
[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(handleEveryNotification:) name:nil object:nil];
}
+(void)handleEveryNotification:(NSNotification*)notification
{
CFShow(notification);
}
Of course, notifications are done with normal method calls, so the first method will also show them (albeit in a big pile of spam).
Delegates are not called or sent; they are just normal Obj-C method calls (strictly "message-sends", but that doesn't have the same ring to it).
If you put a breakpoint into your app, you can watch the call stack change while you step through the code. That's probably as close as you're going to come to what you have in mind.