Frequently Asked Questions/Support

If you have trouble with some aspect of using OpenEars and you have carefully re-read the documents and examined the example app without it helping, you can ask a question in the OpenEars forum (please turn on OpenEarsLogging and — if the issue relates to recognition — PocketsphinxController’s verbosePocketsphinx property before posting an issue so I have some information to troubleshoot from). The forum is a place to ask questions free of charge, but free private email support is not given for OpenEars. However, you can purchase a support incident if you would like to discuss a question via private email.

FAQ

Q: When I license an OpenEars plugin (not OpenEars, one of its plugins), the license is for one app. Does that mean I need a license for each app user?

A: No, the license is for the app itself, so you need one license for one listing in the App Store. No matter how many users your app gets, it’s just one license needed, and we hope you get a whole lot.

[TOP]

Q: My app crashes when listening starts

A: This is pretty much always because the acoustic model wasn’t successfully added to your app. If you turn on OpenEarsLogging and verbosePocketSphinx you can verify it by searching for an error with “acmod” in it. To fix it, follow these instructions from the tutorial: “Inside your downloaded OpenEars distribution there is a folder called “Frameworks”. Drag that folder into your app project in Xcode. Make absolutely sure that in the add dialog “Create groups for any added folders” is selected and NOT “Create folder references for any added folders” because the wrong setting here will prevent your app from working.” A missing acoustic model has been the cause of every crash report I’ve received in the last year with only two exceptions, so even if you’re pretty sure that you added the acoustic model, double-check that the files found in the Framework folder are all present in your app.

[TOP]

Q: There is a bug on the Simulator/recognition isn’t good on the Simulator

A: OpenEars has a new low-latency audio driver written in Audio Units which requires an Audio Session setting in order to work which isn’t supported by the Simulator. Because I know that it can be slow to debug app logic without using the Simulator, I have provided a second audio driver that is compatible with the Simulator. However, it isn’t as good as the device driver and I have spent very little time trying to debug it since I am only providing it as a nicety. With that understanding, please don’t evaluate OpenEars’ accuracy or behavior based on the Simulator, since it uses a completely different audio driver, and please don’t report Simulator-only bugs since I don’t actively support the Simulator or its driver.

[TOP]

Q: I saw a leak in OpenEars, will it prevent my app from being accepted?

A: In the current version there is a leak in a function called cst_safe_alloc that leaks 16 bytes when recognition is started. I have not been able to isolate the cause of the leak and it seems to be a very important function for Sphinxbase so I’m hesistant to get too radical about it. The leak is miniscule and would take a little less than 50 days of continuous recognition at one complete restart of the recognition loop per minute in order to leak a single MB at the given leak size. I have never heard of Apple rejecting an app that used OpenEars so this isn’t top priority but if anyone can see the fix for the leak by all means let me know.

[TOP]

Q: I’m getting a linker error with RapidEars, NeatSpeech, Rejecto, SaveThatWave, or another plugin — what should I do?

A: This is always due to the fact that the plugin requires a certain version of OpenEars or later, and you are using an earlier version, or an earlier version is still somehow linked to your project. The minimum required OpenEars version is always mentioned in the plugin docs, or you can always just use the latest version found on the main OpenEars page.

[TOP]

Q: I have tried a fix for a known issue which others have been able to solve definitively, but it doesn’t work for me.

A: Many, many developers have reported situations like this that were fixed with complete re-installs of OpenEars. That suggests that not every change is always being picked up for them during new compilations for whatever reason (maybe you have different build settings in your preferences, not sure). If your system is manifesting the same symptoms of not picking up a change that others have reported as helpful to a specific issue, it shouldn’t be necessary to completely re-install OpenEars in order to experience the same benefits — just remove the app from your device and/or simulator, and then open the library and your app respectively in Xcode and select Product->Clean or type Shift-Command-k. Then you should be able to do a fresh compile and install. The initial compile will take some time, so go have a cup of tea or make a sandwich. Another issue that has similar symptoms is if you have Xcode set to automatically save when building, and you make a change to a .h file that is a search header of a project but not actually in the file navigator of the project — in order to see such changes reflected in your build, it is necessary to manually save your changes first because a linked search header doesn’t fall under the category of things Xcode will automatically save for you before doing a build.

[TOP]

Q: What license does OpenEars use?

A: There are actually five libraries used by OpenEars-enabled projects, only one of which is the OpenEars framework, and you can see the license (which is very liberal) for CMU Pocketsphinx, CMU Sphinxbase, CMU Flite and CMUCLMTK here. You need to observe the terms of those licenses in your app as well as the OpenEars one, which shouldn’t be difficult since they are commercial-friendly licenses.

OpenEars is licensed under the Politepix Public License version 1.0. It gives you the right to use OpenEars to make apps. You have some obligations (such as crediting the libraries involved) so please read the license.[TOP]

[TOP]

Q: So I can use this in commercial, closed-source apps?

A: Yes.

[TOP]

Q: Can I or should I reference OpenEars in my support/marketing/etc materials?

A: I’d love it if you want to talk about OpenEars in your marketing! If you want to discuss it in your support documents, just please do so in a way that it doesn’t cause any confusion for your endusers about where to seek support (i.e. it must be clear that you are responsible for supporting your app) and it doesn’t imply an endorsement of your app by Politepix or any of the maintainers of the libraries that OpenEars links to.

[TOP]

Q: How can I trim down the size of the final binary for distribution?

A: You can optimize the final binary size by opening the Target Info window for your app, navigating to the Settings pane, and (for the release or distribution configuration of your app, don’t do this for debug) searching for the setting called “Deployment Postprocessing” and make sure it is checked. This should reduce the size of the included OpenEars/Pocketsphinx/Flite code in your final binary by about 8MB. Remove any unused voice frameworks, including the Slt.framework if you aren’t using any voices. If you aren’t using any speech recognition you can remove hub4wsj_sc_8k from your app. If you aren’t using any language model generation you can remove cmu07a.dic from your app. Something else that will always help a bit is to limit how far back you support other iOS versions. Search for the build setting iOS Deployment Target and set it to something closer to the base SDK version you are supporting, for instance using a Base SDK of 5.0 and an iOS Deployment Target of 4.3 means that a lot of devices can run your app but the binary will have minimal bloat.[TOP]

[TOP]

Q: I thought that this version of OpenEars supported the -all_load linker flag, but I’m getting a duplicate symbol error when I use OpenEars with the flag enabled.

A: This version of OpenEars has been tested with the -all_load linker flag and it works, however, a side-effect of using this flag is that every possible class will be checked for duplicate symbols whether they are used anywhere or not. If you are getting duplicate symbol warnings with OpenEars and the -all_load linker flag, that means that another library or class that you link to (unrelated to OpenEars) uses the same method or function names as something in OpenEars or elsewhere in your app. The only thing to do here is to find the duplicated method or function name and change it in one case (and make sure that every single place it is called is also changed to reflect the new name). Although I’m willing to support the ability to compile OpenEars itself with the -all_load linker flag, I can’t support any/all issues which can come up as a result of choosing to use -all_load, and namespace issues are better supported by libraries that require that flag. At this point, it is no longer a necessity that any framework require that you use the -all_load flag, so you might want to let them know that it’s time to drop -all_load.

[TOP]

Q: Have any apps ever been rejected for using OpenEars?

A: I have never heard of any apps being rejected for using OpenEars, and I wouldn’t expect them to be since I’ve taken care to make sure OpenEars doesn’t do anything questionable, and where I’ve had any questions I’ve just written Apple and asked them for guidance directly. I have heard of many apps that were accepted that used OpenEars so it seems to be fine to use OpenEars. I hope that if anyone ever has an issue getting an OpenEars-enabled app accepted because of something to do with OpenEars specifically, they will fill me in.

[TOP]

Q: I still have a question, how do I get more support?

A: You can always ask for help in the forums and I’ll do my best to answer your question. Please turn on OpenEarsLogging and (if the issue relates to recognition) PocketsphinxController’s verbosePocketsphinx property before posting an issue so I have some information to troubleshoot from. Free private email support is not given for OpenEars, but you can purchase a support incident if you would like to discuss a question via private email. Forum support is free. Other emails regarding OpenEars (i.e. not support requests) can be sent via the contact form.

[TOP]

Q: Can I hire you to create an OpenEars-enabled app for me or adapt OpenEars?

A: Send me a note and we can discuss it if I have availability. You can now also purchase a pre-configured app project or an integration of OpenEars into one of your existing apps at the Politepix Shop.

[TOP]

Q: Did you change the title of my post/remove my post/move my post/otherwise moderate something on the forums?

A: I may have — I want the forums to stay as small and focused as possible so that the answers are right there near the front page of posts and there isn’t confusing, contradictory, outdated, overly-speculative or off-topic info in there (where on-topic == “about implementing OpenEars”), so I take out the scissors from time to time if I read something that I think is kind of a clanger or mis-titled, mis-tagged, etc. It means that it isn’t a great place for free-form conversation but it’s a good place to get a reliable answer about OpenEars implementation. I don’t think this is unusual for a troubleshooting forum, but I wanted to make it explicit since I like to know what the moderation policies are for forums that I visit.

[TOP]