We began migrating our sound-engine to XAudio2 some time back, but are not complete yet. At present we're stilling using OpenAL and have hit an issue where the maximum number of 'sources' (what I believe are termed 'voices' in XAudio2) varies depending on your hardware.
We could upgrade our OpenAL stuff to recycle sources, but if XAudio2 solves this for us then I'd rather focus on completing the migration.
I have not been able to track down any info on this and don't see any posts from people struggling with this issue with XAudio2... so I'm guessing there is no limit?
There are no hard voice limit on XAudio2 as it's all software mixing, but there are practical limits based on your target hardware that typically result in glitching as the mixer is unable to keep up.
XNA Game Studio enforced a limit of 300 voices on Xbox 360, so that's probably a practical upper-limit for 'modern PCs' that are trying to run full 3D games at the same time. Number of 3D positional voices, number of effects/DSPs running, and other factors will also lower that number a fair amount.
Generally having more than 64 playing sounds is likely to be hard to pick out, so most voice-management systems reuse a reasonable subset of voices and assigns them dynamically. For example, DirectX Tool Kit for Audio voice management defaults to "unlimited" voices, but supports a mechanism for setting the maximum number of voices to allocate for 'one-shots' and 'instances', reclaiming a voice pool, etc.
Related
I'll start with the question.
Is the BTLE RSSI a good way to indicate two devices proximity to each other or not? does it only work with small devices like fobs etc?
The Issue:
I am currently looking at making an app that will use BTLE and allow connections based on proximity. In this regard it is much like the demo app that apple show in the Advanced Core Bluetooth keynote (When two devices are almost touching they then connect).
As I understand it the proximity is determined based on the RSSI value when the central discovers the peripheral. When I try this however with two iPads the signal seems too strong for this it is also too inconsistent to have an accurate stab at the proximity as it doesn't show very much correlation to the devices proximity.
I have tried the Apple sample code and that is similar in that the devices don't have to be close at all for the information to pass from one to another.
If only there was a way to reduce the signal strength of the peripheral devices advertisement....
Thanks in advance for any help.
The experience of Matthew Griffin matches mine. However - when we can measure for a fair period of time two things have helped us calibrate this better.
We did have to wrap a simple (kalman) filter on the antenna orientation and the IMU to get a rough running commentary though - and this is not very CPU or battery light.
Using the IMU you get a fair idea of the distance/direction of travel - and if this is over a short period of time - we assume the other 'side' is stationary. This helps a lot to get a value for 'current' orientation and 'callibrate current environment noise.
Likewise - do the same for rotations/position changes.
We've found that in general a re-orientation of the device is a better way to get direction; and that distance is only reliable some up to some 30 to 600 seconds after a 'move' calibration' and only if the device is not too much rotated. And in practice once needs some 4-5 'other' devices; ideally not too mobile, to keep oneself dynamically calibrated.
However the converse is quite reliable - i.e. we know when not to measure. And the net result is that one can fairly well ascertain things like 'at the keyboard' and 'relocated'/moved away through a specific door/openning or direction. Likewise measuring a field by randomly dancing through the room; changing orientation a lot - does work well once the receiver antenna lobes got somewhat worked out after a stationary period.
You are entirely correct about RSSI jumping wildly and randomly. You should retrieve your RSSI values every two seconds (any faster and you get a bunch of errors). Throw out the RSSI values that are more than a ~-40 decibel spike and use an aggregate of the past values before you declare your approximate range to the user.
As for your following statement, you are in luck.
If only there was a way to reduce the signal strength of the
peripheral devices advertisement....
The service you are looking for is called the TX Power Service. Implementing this service on your peripheral will allow you to decrease the transmit power of the device. That way you can throttle down the range that the advertisement data is visible from. We unfortunately do not however, have access to this service on an iOS device. But if you are writing your own firmware for a BLE peripheral, this is the service you want.
I've spent the last week dealing strictly with RSSI, trying to use Wifi and Bluetooth LE sensors for location triangulation and for distance conversion.
Unfortunately, what I have found is that RSSI is just too finicky and unreliable to consistently use to determine distance. In theory, the RSSI and distance behave according to the inverse square law (double the distance, and the RSSI will go down a fixed number of decibels), but in practice the RSSI is affected by uncontrollable factors such as weather (dry weather allows RF fields to travel better) and obstacles (any metal objects or humans in the path from one sensor to another will cause attenuation, and any metal objects closely positioned by one of the sensors will cause gain in the signal strength).
There are ways to try to compensate for this. This paper is one of the best papers I read on how to get accurate results, but the bottom line is that is an unreliable method unless you just want a general idea of where the device is.
If I understand well, you are trying to implement similar functionality that to what seen in the WWDC demo and what apps like Bump implement. For that RSSI will be adequate. Test for appopriate threshold values (e.g. >-30) and you will be fine.
What I want to do:
I want to have my iPhone to frequently (formally defined later) upload my GPS location to a central server. I want to do this in the most battery efficient way.
Research I'm aware of:
Apple Documentation:
https://developer.apple.com/library/ios/#documentation/CoreLocation/Reference/CLLocation_Class/CLLocation/CLLocation.html#//apple_ref/doc/uid/TP40007126
Stack Overflow Links:
Response 1
Response: proof of existence; some other tool can do it
How to reduce iPhone battery consumption while using GPS
Response 2
Response: track only cell tower changes
iPhone GPS - Battery Draining Extremely Fast
iPhone running periodical process in the background - battery optimized way
Question
My question is a bit vague in that my definition of "frequently" is really dependent on what the battery life can tolerate. For example, if the battery can take updates of every 5 minutes, I'd like to do it every five minutes; if the battery could do this every 10 seconds, I'd like to do it every 10 seconds.
I really want to understand
the different ways (change on significant location, timer, background?) continuously uploading GPS locations can be implemented
advantages / disadvantages
approximately how long the battery life can last in each case
This seems like a fairly generic and common problem. Does anyone know of either:
an in depth analysis of the various methods
or if there is a single "optimal" way to do this?
[Moderators: feel free to mark this comment wiki. I'd love to just get lots of different answers + cost benefit analysis of them.]
Have a look at the Apple Documentation Here.
The significant-change location service offers a low-power location service for devices with cellular radios. This service is available only in iOS 4.0 and later and can also wake up an application that is suspended or not running.
It all depends on the use case. If the user will stay at a certain location and all you want to do is to track if he is leaving the country, tracking the significant location changing will be most suitable. However, this will not be precise enough for navigation apps.
One advantage of choosing the "Apple-Algorithm" is that they'll optimize it for you, if battery issues occur. (-:
I've heard of geofencing and I have some doubts. Hope you can answer some of them.
-It's new for iOS 5.1 but what is the difference between geofencing and Using Regions? From what I've read is nearly the same, the battery drain?
-Why can't I find apple documentation on geofencing?
-How do you define the regions? can I add them remotely, via webservice?
Thanks.
Geofencing has actually been around since iOS 4. You can find documentation on it in the Apple Location Awareness Programming Guide. It is also referred to as "region monitoring".
The regions are pretty simple to use. Create a CLRegion with the center point (lat, long), radius, and a unique identifier. Then call the -startMonitoringForRegion. Granted you will need to register a CLLocationManagerDelegate to listen for the callbacks, -didEnterRegion and -didExitRegion, but that is pretty easy to do as well.
You can't add them remotely. Only from the device. I have learned a few things about them over the last couple years. So hopefully this will save you some trouble down the road.
Not all devices can monitor regions, so make sure you check for availability
There is a min and max region size. If you register a region over or under those values, it will default to the min/max. The min is 100M, max is something like 1/3 the size of the globe. Pretty large.
There is a max number of regions 1 device can monitor. This "pool" of regions is shared by all apps, and older fences will get purged to make room for newer fences. So be prepared for that. The max number is close to 100. But shared between passbook apps, reminders, and other apps... can get burned up pretty quick.
Make sure you only have one instance of your location manager delegate, multiple instances will get you multiple delegate calls, they are all listening.
Geofences are a great way to add functionality to locations without any of the overhead active GPS and location tracking has. In my experience, geofences pose no noticeable battery drain when leaving on all the time. Apple has them figured out pretty well. They don't carry the same accuracy as active GPS, but they are close enough. Good luck.
UPDATE
Some of the information here is a bit dated now. The number of regions you can monitor is now 20 and is capped per app. Also, the minimum size is not 100M, it can be smaller, but accuracy is not guaranteed at lower numbers.
"Geofencing" has always been around, since iOS 4 in the form of "Region monitoring". It uses distance checking to see if you've entered a circle. This is not true geofencing, as true geofencing is checking if a point lands in a polygon (called point in polygon).
As of iOS 6, there is currently nothing akin to region monitoring that uses point in polygon. To do true geofencing, you would have to use a combination of Region monitoring and GPS. There is no Apple documentation for geofencing because CoreLocation doesn't support it.
If you are going to take the point-in-poly approach, I would recommend ray casting. There is an Objective-C class that implements it really well. It's called objc-BorderPatrol.
As for sending fences from a web service, it may be possible to do something similar to Twitter's streaming API, but that may be too intensive. It's better to use Significant Location to update your fences. If you're going to send fences from a web service, I would recommend using MySQL or PostGRE SQL as both have really good geospatial extensions.
A few caveats:
-> -[CLRegion containsCoordinate:] is never called by any CoreLocation object. All of the distance checking is internal.
-> Significant Location updates every 500m or 5 minutes, whichever comes first. Significant location uses the IP address from a cell tower to determine location.
-> Geofences and regions can overlap, keep track of this.
I'm looking into the new background location service options in the iPhone 4 SDK. It allows an app to run in the background and receive location updates from the device.
There are two methods offered. One is a battery intensive mode that continuously gets location updates. The second recommended method sends the app location updates when there has been a "significant location change".
Does anyone know what a significant location change might be? Is a 30 foot walk considered significant, or is a 10 block walk considered significant? I imagine it also depends on the accuracy of the location mechanism being used at the time.
I've recently done some field testing of the new background location service to get an idea of what constitutes a significant location update, what kind of accuracy to expect for the location hits and our general experiences using it.
The results are detailed in a fairly lengthy blog post:
iPhone Background GPS: Accurate to 500 meters, not enough for foot traffic
As Steve Jobs mentioned in the OS 4 introduction, the low power mode uses cell tower triangulation and does not activate GPS unit. Since the iPhone phone module needs to keep a connection to the cell network anyway, there should be no impact on battery life.
Since the precision of a location fix with cell tower triangulation is anywhere between a few dozen meters (in dense city locations) and a few miles, I think 30 ft is not a significant location change. I don't know the specifics, though (and as mentioned by the commenters, the Apple dev forums are the right place to talk about those).
Our lovely app that downloads mp3s from our server into a local file on the phone then plays from that file was rejected for using too much bandwidth.
I understand the rejection (we are downloading rather than streaming) and don't quibble with their decision... our first priority was quality of user experience.
I am just wondering... what do I do now?
There are no hard and fast rules... Apple just says, "Must not in Apple's reasonable judgment excessively use or unduly burden network capacity or bandwidth".
Anyone have data on what Apple considers reasonable data transfer rates?
Should I fill up the buffer file in short spurts? Should stream the file at a constant rate (and how would I limit the transfer rate from within the app?)
Any and all suggestions are welcome.
Thanks
I have talked with Apple Developer support, and just FYI. You are only allowed to stream 1 MB per minute over the Cellular network. Support suggest that you test your app in the following way:
"The basic measurement methodology is to turn off all background updating (particularly Mail's automatic mail downloads and Calendar updates), reset the transfer statistics in "Settings:General:Usage:", and then launch your application. Let it run for a fixed amount of time (five minutes is reasonable), and then exit your application. Once you've finished the test, the numbers listed under "Cellular Network Data" in "Settings:General:Usage:" are what you should focus on reducing.
Using what I just described, I'd suggest 4.8 MB every 5 minutes as the guideline you use to ensure your application stays within our bandwidth requirements."
Hope that helps at least a little.
Have you considered HTTP Live Streaming? It's built into OS 3.0.
Basically, you split your media into small (say, 10 second) snippets and put it on a standard web-server. Then you create little text 'meta-descriptor' files in EXTM3U format that point out where the bits are. The interesting thing is that you can create multiple versions of each snippet at different bit-rates. So if your bandwidth is good, the iPhone player dynamically chooses the higher bit-rates but when it's low it automatically switches to the lower bit-rate version of the snippet. It does this on-the-fly to adapt to changing conditions.
So if you split your MP3 into multiple 10-second bits at say, 3 different bit-rates then when the user is connected through WiFi they get the high-quality stuff but if they're on 3G or EDGE they get progressively lower-quality (and smaller sized) content.
If this violates your downloadable media concept, then perhaps you can use the same trick and keep multiple size files for each connection type. Then if you're on WiFi (or get a fast turnaround on a heartbeat ping to the server) download the big file vs. medium or small size ones.
Here's a decent step-by-step on segmenting content. They focus on video but it should work with audio content as well.
I would suggest throttling the bandwidth on the network/http request when connected to cellular, and having no throttle on wifi.
A combo of using Reachability to detect the network status, and implementing your http request using CFNetwork with a sleep until the next second whenever you have already downloaded as much as allowed per second should get you there.
You should check out this project, either to use, or just to see an example of how to code this well:
http://allseeing-i.com/ASIHTTPRequest
The ASIHTTPRequest class implements this, using either the old or 2.0 version of Reachability, and also provides a class level throttle, so even if you have multiple concurrent downloads and uploads, so long as all of them go through ASIHTTPRequest, they will be properly taken together and throttled properly.
A bit more on how to use this here:
http://allseeing-i.com/ASIHTTPRequest/How-to-use#bandwidth_throttling
Lots of good stuff in this (and no, I am not the author of any of it).
On a more serious note, what is it trying to do? There are many markets for iPhone outside of the US which don't have good download rates for phones, nor are the download cap sizes good, so having an app do lots of downloading isn't a good thing.
Could you possibly drop the data rate on your mp3 or some such? Make it optional to do the downloading with a warning that it will use your download?
YOu could not download the mp3 unless you are on wireless, and inform them of that. If you the mp3 are too important, then just tell them it only works on wireless, or include a few mp3 on the device. But 30min of mp3 is ridiculous, that is about what, 30meg.... think about it, 30 meg is just too much.