So I found out that AudioKit is automatically enabling Microphone capture upon AudioKit.start. This also happens in the Playgrounds and is 100% reproducible.
Turning off AKSettings.audioInputEnabled does not seem to help. Besides the fact that it looks like a security risk to any user using MicroSnitch or similar, it also produces problems with BlueTooth Audio, which may automatically downsample for a lot of connections if microphone input is enabled.
Is there another way to turn this off?
Related
I've just acquired a HDMI recorder card, and I'm trying to digitally capture the output from my game using the HDMI out from a iPhone 4S.
Problem is software keeps complaining that the content is copyrighted and cannot record.
Is there a way I can setup the HDMI stream so that inside my game the HDCP copy flag isn't on ?
Even looking forward letting my costumers record their gaming sessions seems like a good idea, I think that's something that I would like to permit.
I'm pretty sure you can't turn off HDCP. That protection standard was founded on the basis that anything with HDCP enabled should never be recorded.
I have a monitor (a new samsung) at home I can't use because its not HDCP compatible, and newer video cards require it :(
Hardware Volume Control
I'm trying to understand what is best practice for apps that are mostly silent but occasionally produce sound. Such apps can take advantage of the side volume control on iOS devices and avoid the need to design in a NSVolume control widget, which I believe is not as convenient as the hardware side volume control. The approach would apply to apps like MapQuest 4 mobile where you get occasional audio prompts that blend well with other music players (using audio ducking) but are silent for the most part. I'm wondering how others are addressing this same issue.
I have developed such a system that works rather nicely. In my approach I query the audio APIs to determine if other music is playing (iPod, AOL Radio, Pandora, etc.) then start an audio session only if no other audio is playing. This ties the hardware side volume control to the app instead of the ringer (for iPhones). The challenge comes when you go to the background. My approach kills (deactivates) the session in the background only if the app is not using audio. If there is audio playing the session is deactivated at the conclusion of the playback.
The idea behind killing the playback is to restore the user's ability to adjust the ringer volume to their liking should my app continue to run in the background.
This question originates from issues I faced when developing the voice navigation feature on MapQuest 4 mobile on iOS in 2008-2009. In this app we wanted the side volume switch to control the volume of the turn advice at all times while the app was running. I later realized that I could not control my ringer volume after arriving at my destination and sending the app to the background. This was years ago but I believe the app was continuing to run in the background which lead to the problem. It is an interesting case, when the user is navigating but sends the app to the background should you continue the audio session? Is is more likely that the user would like to change the app volume or the ringer volume while the app runs in the background?
My general use case (when I posted this question) involved navigating in the background while running another app in the foreground (commonly a music player). However it is also common for the navigation app to be sent to the background while the user sits on the home screen. This is when it would make sense to deactivate the audio session.
It is not as straight forward as it seems but my approach works for most cases. Still I am wondering if there are other more viable solutions to the problem. What are other people doing? Would it make more sense to just include the volume control in a view that auto slides in/out of place? Are there things that I have not considered? How have you approached the problem? Do you have any general suggestions?
I'm looking for some way to let my app play a sound at a specific time while it's in the background (IOS4 multitasking). Currently, I use local notifications for that which works quite well, except for:
the sound will not be played if the phone is muted
the 30 second playback limit
I saw there's setKeepAliveTimeout:handler: but it's only available for voip-apps and since that's not the purpose of my app, I guess Apple would reject it because of this. I also saw a solution where an "empty" sound is being played until it's time has been reached, but - ignoring that this is not a very elegant way, anyways - I read that this, too, might get the app rejected.
Since there are a few alarm clock apps that do just what I'm looking for, I wonder how they implemented this functionality.
Thanks for any hints in advance!
If you seek a solution that will be approved by Apple, you're right you can't use the setKeepAliveTimeout:handler and even if you could - you can't set the timeout to something that's smaller than 600 seconds, so I guess it won't be of a great use anyway (besides that It's not guaranteed to fire the event even remotely close to the timeout you specified. For example, I set it to 600 seconds and some event fired as early as 360 seconds..).
About playing the silent sound, except the waste of battery, if you're app has legitimate use for background audio (if you're implementing an alarm clock, that's pretty obvious), I don't see a reason for your app to be rejected, as long as you don't try to use other background features (GPS signal, VoIP handlers, etc).
Here's one example app that used this "feature" for their benefit:
http://tapbots.com/blog/pastebot/pastebot-music-in-background
About other methods, you can look in this thread:
How do I start playing audio when in silent mode & locked in iOS 6?
On a personal note, it's not very easy to cope with background policies of Apple. Me and my company had (have?) a hard time just to maintain a simple VoIP connection due to all the limitations. My best advice is try to do as less as possible in the background as you can. If the UILocalNotificaion solution suits you, you'll probably should stick to it and live with the limitations.
I am trying to process a blowing sound in my iPhone app. I tried both solutions below. They both work fine in the simulator but not on my device.
http://www.mobileorchard.com/tutorial-detecting-when-a-user-blows-into-the-mic/
https://github.com/stephencelis/sc_listener
I have seen similar questions around this topic but haven't find an answer yet. Do I need to turn on something in my app or settings?
Diferent sound cards have different 'gains' or amplifications. I had an issue with an app that detected DTMF sounds. It worked perfectly on my pc but not on other machines.
Phones also have noise cancellation systems and that may be causing the issue. Have you tried diferent devices?
Maybe you should create your own app that renders a sound pitch value and see what happens...
The iPhone 4 has two built in microphones, one in the standard place and one sitting next to the headphone jack. I know this new mic is used for noise reduction in calls but it is also used on facetime, videoing, speakerphone calls etc.
I have a valid reason that I want to be able to choose which mic to record from, be it the new one or the old AND even both at same time.
Does anyone know how to route avaudiorecorder so I can choose any of the above options of what is being recorded?
Thanks in advance
I know this is an ancient question, but for future reference in case others are looking for the same answer, I'll put some information here. There is a section in the AVAudioSession documentation that explains that since iOS7, there is a way to do this explicitly:
Using APIs introduced in iOS 7, developers can perform tasks such as locating a port description that represents the built-in microphone, locating specific microphones like the "front", "back" or "bottom", setting your choice of microphone as the preferred data source, setting the built-in microphone port as the preferred input and even selecting a preferred microphone polar pattern if the hardware supports it. See AVAudioSession.h.
In older OS's, you could only choose the AVAudioSessionMode to affect the choice of microphone.