Is there any way to let's say, user clicks a button, and then he needs to say something to the mic, but only after he finishes to talk to the mic, the app will wait 5 seconds, and then the app will do something. is there any code or example for this? to check if there is an input to the mic or not.
thanks in advance!
If you're recording with AVAudioRecorder, you have the ability to enable metering and get basic power metrics for your current recording. One way to determine silence for a period of time is to sample the average power and peak power over a time period of your choosing (1/2 second to a few seconds). If the ratio remains low enough during that arbitrary period, the input has been relatively quiet and you can end the recording. You can view the docs for that class here. If you're using Audio Queue Services, this may be a little more involved, but the concept is the same.
Related
I want to replicate some of the functionalities of sleeptrakcing apps like AutoSleep. Apparently I can not open the app for a day or two, and when I open it up, it can accurately access the sensor data on my Apple Watch to see if I'm moving or not at any given 15 minute interval.
I've tried looking at various functionalities of CoreMotion. The closest I've seen is using CMSensorRecorder and call recordAccelerometer to start recording. However, this only allows you to record up to 12 hours. And the user would have to start the app to start recording. This is clearly a limitation that AutoSleep doesn't seem to have, because it seems to get the data out of thin air.
Anyone know how it's possible to get historical Accelerometer data from WatchOS that stretches back a long time without actively recording it?
I wish to build a timer with a start button that once pressed begins to monitor environmental decibel levels through HealthKit. And then once a decibel passes a threshold I wish to log event.
Is something like this available through health kit? Can I actively monitor decibel levels of my environment? Almost as how the native Noise app currently works on the Apple Watch. But I wish to gather this data when the user clicks a start button.
If so, how often can I sample this data? Can I get distinct decibel events that occur between each other within less than a second? A half second? A tenth of a second?
I have to perform an action (play song at a time on multiple devices without lag) at a given point of time. My requirement is that the app should not use any internet connection. So I need an exact point of time when to play data(Audio)]
I have already tried following:
Play song after 5 seconds on all devices. (still causes lag of milliseconds)
Send a small text notification to identify playing of the song and then start playing on all devices. But sending and receiving this notification takes time of milliseconds :(:(
Set time to automatic on all devices and then checked time difference of text message passing, It has milliseconds gap in each testing.
First you need to synchronize the 2 devices internal time.
Apparently the most accurate clock you can have on iOS is the absolute time by doing :
CFAbsoluteTime now = CFAbsoluteTimeGetCurrent();
Then you need to send this time from device A to device B retrieve the difference on device B and send it back to A , then compare the difference with the time spent in the network transaction. In this way you can have a quite accurate synchronisation of the 2 devices time. (This is presuming the network time is symmetric between request and response and that there is not much overhead on your calculation on device B).
From there you can easily instantiate 2 AVAudioPlayer on the devices set the song and call prepareToPlay and finally fire the play method according to the delay on the synch.
This should give you a not noticeable precision.
Another route you can take is the one of placing an AudioUnit on the second device connected to the microphone in order to sync the music accordingly to the first device emitted sound.
Known Issue
When sleeping or waiting for extremely precise time intervals, timers may be delayed by up to 1 millisecond.
For reference :
https://developer.apple.com/library/ios/releasenotes/General/RN-iOSSDK-7.0/
I want to create an (game based) iPhone application which sends your GPS location on a specific time (like 3-5 times a day) to a server. I found an apple page explaining some functionality to run in the background like location, music and VOIP.
I need the GPS to be accurate on the meter.
Can someone help me with a small example?
It really depends on your usage of the location. If you monitor actively, kiss the battery of your user goodbye. Very detailed accuracy, even bigger hit to battery. The backgrounding of location is all or nothing as far as accuracy goes.
Less hit, less accuracy is -startMonitoringForSignificantLocationChange. May not be accurate enough for you.
Better depending on usage, region monitoring. Triggers event on entry or exit of defined region.
You don't have the benefit of accuracy and timed location based events. You can do it, but is going to require a lot more effort on your end.
While this is untested, I am planning an app with a similar need. My solution is that on a significant location change, the app will determine what interval exists between the update timestamp, and when I care to know the users location (5pm for instance). If that's below some threshold, it will go into startUpdatingLocation mode (full power, battery draining, which is why that threshold is important) and then, on each location update, check if that target time has passed. if SO, send the update to your server, and go back to monitoring for significant changes. The catch is that if it still requires some movement to trigger the significant change update...so it isn't a perfectly reliable solution, but it may work depending on how you're using the data
You can't "schedule background work". iOS doesn't allow it.
The solution is to set yourself up for notification on significant change (which is some hit to the battery, but it's not horrible), and then only DO anything with that at occasional intervals.
A common exploit in casual games is to artificially advance the system clock to jump ahead in gameplay. How can such user clock advancement be detected by an app on an iOS device?
Must not involve network communication
Must not assume app is open (running or suspended) while clock is advanced
Must detect clock advancement, detecting clock rollback is not sufficient
Ideally, the solution would be robust against reboots, but that is not a requirement.
CACurrentMediaTime & mach_absolute_time
Take a look at this questions:
iOS: How to measure passed time, independent of clock and time zone changes?
Calculating number of seconds between two points in time, in Cocoa, even when system clock has changed mid-way
CACurrentMediaTime uses mach_absolute_time:
http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/CoreAnimation_functions/Reference/reference.html
Here you have an example on how to use CACurrentMediaTime:
http://www.informit.com/blogs/blog.aspx?b=02b4e309-308c-468a-bab1-cebb1404be6a
Here you have a more information on mach_absolute_time:
http://developer.apple.com/library/mac/#qa/qa1398/_index.html
http://shiftedbits.org/2008/10/01/mach_absolute_time-on-the-iphone/
I was thinking about the fact that the CoreLocation stuff could do this if that part of the GPS data was exposed to you. However that got me thinking.
My only (far fetched) suggestion is to put something into background processing - which has to be for one of a small specific set of reasons, for example to track location in the background. As a side effect of that, try to detect a clock change on a regular timer. Apple might reject it as it may be clear that its not using the location information and its just a reason to exploit background processing.
Any solution not involving networking is so much harder to implement, I wonder why you're not using it.
Whilst I don't think it's possible to reliably determine whether or not a user has manually turned their clock forward without network access, you can of course reliably determine if they've travelled back in time. And since we know this to be physically impossible it can therefore be assumed they have manipulated their clock to cheat.
What I mean by this is, isn't the usual process to trigger some action in-app that requires a period of waiting, exit the app and turn the clock forward, re-launch the app to gain whatever they were waiting for and then reset the clock back to the actual time?
If this is indeed the case, then to build on the suggestion by #smgambel, you could store the physical time and current time-zone on each launch and compare with the previously stored time and time-zone. If the time is behind the previously stored time, and the time-zone of the device hasn't changed then you can safely assume the user has manipulated the clock.