I am new to iOS, i have a problem which need to find the available audio routes in iPhone (iOS7)? (like if headphone is connected it should be both iPhone and headphone,if Bluetooth and headphone is connected it should
be all the three).
I have tried [[AudioSession sharedInstance]current route].outputs, but it is giving the current route(currently
active route) details only, i have also tried the outputDataSources property of audioSession, but it is giving nil value.
Can anyone suggest a proper solution for this if apple is exposing API's for finding the available routes.
Related
So with iOS 8, we can now record the screen of iOS devices. I've searched extensively and cannot find a way to detect, let alone prevent, this recording. The app I'm working on deals with some potentially sensitive information and images and would like to prevent this if at all possible.
Thank you in advance for your responses and insights!
Anthony
Apparently, there is some way to detect whether a display or QuickTime streaming is connected, because the Netflix app will show an error when that is the case (which also means you can't just use an iOS device and stream to your computer to watch it in big). The app works perfectly if QuickTime streaming is off with the cable is plugged in.
Maybe it just detects whether an external display is connected, and screen recording behaves like that, so basically you might have some success with these APIs and notifications.
Also, you could use an encrypted HTTP Live Stream according to Apple which would be blacked out in the stream / the recording.
I just fired up the new Netflix app for iOS and upon trying to AirPlay the video to my Apple TV, I got this message:
So I was wondering how they're able to do this. Is there a public API that lets an app retrieve the version of the Apple TV that's selected for AirPlay? Or does Netflix use some other means to detect this?
It's actually not that difficult to be able to pull something like this off. We're going to need to be doing two things: 1) listening for when the audio route changes to know when we've connected to an AirPlay device, and 2) searching the network for AirPlay devices to get info from.
Once we get notified when the audio route changes, we can get info about the new route. The most important bit for us is the name of the output port for the AirPlay device. Once we have that, we can iterate through all the AirPlay devices we know about to find the one that matches the name of the output port. Once we have that device, we can get info from its TXT record, which contains info about the version of the software its running.
I've pushed a sample project to Github that details how I pulled this off. This is a really simple project that just handles when a route changes. If you wanted to go live with this code, then you'd also want to add checks at certain other places, like when you present an MPMoviePlayerViewController.
EDIT: Note that this is pretty hacky, as we rely on the name of the port to be the same as the name of the AirPlay device. If Apple changes either of those things, this breaks. Alternatively, you can compare the "deviceid" field of the TXT record of the device to the UID of the port, which is the deviceid with the string "-airplay" appended to it, as far as I can tell. Again, if that is changed by Apple, it would break, but at least it's another potential way of checking.
Hey I have a video app which uses AVPlayer, I received an email from a user saying he couldn't use his car's bluetooth anymore since I updated the app some time ago.
Now, I didn't tried to support bluetooth back then, but apparently this functionality came along with MPMoviePlayerController which I used before.
Is there a way to check if there's a bluetooth device connected and to send audio to it?
I've seen this question, but it didn't help, the volume control shows but no button letting me chose the output.
Do I have to do something else in order to use bluetooth as output?
I've only tested with my car's bluetooth, which works with phone calls and also other apps like Viber.
We created an external iOS notification light that uses the device’s audio for power.
When you get a phone call on iPhone and the light is plugged in, you still get the ringtone but when you pick up, the audio is rerouted to the headphones (the iPhone thinks our light/device is a headphones set) and the user has to extract myLED for at least 2mm to get the audio from the front receiver of the phone.
We have been exploring alternative solutions to this challange - recently we made a prototype with a particular jack shape so that it could be rotated by the user when getting a call to "reroute" the audio to the iPhone speaker/mic.
Although it may sound a clever option, this hardware solution is far from being neat - this leads to having positions where the myLED does not work/ it is not reliable, plus other complications.
I know of the existence of kAudioSessionOverrideAudioRoute_Speaker however I suspect that this will only direct the app audio to the rear speaker (the “loud” one) and not to the front receiver (because the “receiver” for the iphone is the headphones set if they are detected).
What would you suggest?
Super appreciated!
I think you're in a tough spot:
It's highly unlikely Apple will ever release the option to override audio routing for phone calls. As a key functionality of the phone, they tend to keep the call aspect under lock and key.
The headphone jack (probably - this is how most of them do it) uses the impedance between ground and one or both speakers or the remote control to determine if the plug is in. Other than breaking the circuit, there is no good way to simulate this.
The only options I think you have are these:
Require the user to remove the device when a call comes in.
Provide a microcontroller on the jack to drive a transistor; this transistor can electronically break the circuit to provide the same sort of impedance signature as an unplugged jack.
How, when, and if you can provide the information to the jack that a phone call is in progress is beyond my knowledge: is there an API for "incoming but not yet answered call" you can hook to? Will you have to do a watchdog thing to ensure communication with your app? Would it be possible for you to use the dock connector instead? I think these are really your options. Not a complete answer, but those are my thoughts.
iOS 6.0 brought "multi-route audio" support to the iPhone / iPad.
DJay app for example benefits of it by allowing the user to hear one deck in headphones while playing the other.
The only mention of it is in the AVAudioSession class reference :
AVAudioSessionCategoryMultiRoute
Allows you to output distinct streams of audio data to different output devices at the same time. For example, you would use this category to route audio to both a USB device and a set of headphones. Use of this category requires a more detailed knowledge of, and interaction with, the capabilities of the available audio routes.
This category may be used for input, output, or both.
Available in iOS 6.0 and later.
How to route two distinct streams to different routes ? Especially using Remote I/O ?
Thanks!
Answering to myself : there's actually no information in iOS Developer Library, but hopefully, there's all the info needed in WWDC developer sessions.
Search for: WWDC 2012 Session 505: Audio Session and Multiroute Audio in iOS by Torrey Holbrook Walker.
I hope that may help somebody else.