Join John Nastos for an in-depth discussion in this video Advantages and disadvantages of System Sound Services, part of Creating Audio Apps for iOS.
- Now, it's time to dive in to the first of the audio frameworks, which is System Sound Services. System Sound Services is the most basic of the audio framworks on IOS. It has limited functionality, but can also be the simplest to set up and use quickly for the right applications. It's probably the right choice if, for example, all you need to do is play alert sounds or user interface sounds, like button-pressing, to the user within the app. First, let's look at the advantages. System Sound Services has a simple API.
There are only a few possible function calls and they require almost no set-up. System Sound Services is the only audio framework that also exposes the ability to control device vibration. This can be used in conjunction with, or separate from, the sounds you're playing, and can be a great way to interact with the user, depending on your app's needs. System Sound Services is the only audio framework that doesn't need set-up with AVAudioSession. Although setting up an audio session is only a few lines of code, if all you need to do is alert the user, it's not necessary to write the audio session code to do that.
Now, the disadvantages. The first disadvantage for a lot of IOS programmers is that System Sound Services is a C API, not Objective-C. Luckily, because it's a relatively simple API in this case, it doesn't add that much complexity, but it is certainly not as familiar and comfortable as Objective-C is to many people. Since this C versus Objective-C API will come up again with Audio Queue Services and Core Audio with Audio Units, I'll take a minute here to describe the difference between a C API and an Objective-C API.
Chances are, if you've written code for IOS before, the majority of it has been interacting with Objective-C APIs. The most common frameworks in IOS, including Foundation and UIKIt, are Objective-C APIs. Objective-C relies heavily on method calls on objects. For example, changing the background color of a view may look like this. This should look familiar to IOS and OS X programmers. First of all, lots of angle brackets, but, more importantly, taking a variable, in this case, the "viewController", accessing a property of the variable with DOT syntax, in this case, "mySubview", and then calling a method, which is "setBackgroundColor".
Then, creating the "UIColor" with initializer on the "UIColor" class type. Also, note that the parameters are named in the "UIColor" declaration. The parameters are "colorWithRed", "green", "blue", and "alpha". All of these things are features of the Objective-C language. C tends to look a little different. Here's an example from the Audio Queue Services code that we'll be looking at later in the course. Instead of objects, properties, and methods, C APIs tend to rely more on function calls and pointers.
Notice that the parameters of the function aren't named. Also, and this is very important, with C APIs, ARC isn't used, and you're responsible for more memory management than you tend to be with Objective-C. Neither Objective-C or C is better or worse. They just look and behave differently. Sometimes, a framework might have a C API because most of Apple's low-level code, and especially the older code, is C or C++, and they didn't write an Objective-C wrapper around it, and instead, leave it to developers to interact with the low-level C API.
Other times, APIs are written in C because in extremely performance-intensive situations, C is faster than Objective-C. With the audio frameworks and APIs that this course looks at, both of these cases appear. Apps that use System Sound Services to play audio probably don't need lots of performances, but the framework is old and simple, so it's the C API. Also, Audio Queue Services and Audio Units in Core Audio are C APIs. On the other hand, AVFoundation is a modern API with fewer performance concerns, so it's Objective-C.
Now, back to System Sound Services. System Sound Services has a time limit on the length of the audio it plays. The audio has to be 30 seconds or shorter. Since it is a framework best suited to playing alerts and notifications, this may not be a deterrent, but it can be a deal-breaker for using this particular framework if for some reason, you need longer audio segments. The audio that System Sound Services plays has to be read from files. It can't be played from blocks of memory or strained. These files are also limited in format.
The files have to be in linear PCM or IMA4 format and packaged in a CAF, IAF, or WAV file. System Sound Services has limited control over the audio it plays. It doesn't have control over level, positioning, looping, or timing control, and doesn't support simultaneous playback of sounds. Also, keep in mind that you cannot play audio in the background using System Sound Services.
- Playing sounds with System Sound Services
- Setting up audio sessions
- Playing sounds with AVFoundation and AVAudioPlayer/AVAudioRecorder
- Recording audio with an audio input queue
- Playing back audio with an audio output queue
- Setting up audio units
- Changing input and output levels
- Responding to events
- Working with third-party frameworks