symba (779893), страница 24
Текст из файла (страница 24)
If you try to stream videocontent with a larger frame size or bit rate than the device supports,usually only the audio component is played. There is a wide variation inmaximum sizes supported by current smartphones from QCIF (176 × 144)up to VGA (640 × 480). If you are producing the content, you either needto provide different versions for different handsets or select a size smallenough to be supported on all of your target devices.
If your applicationuses third-party content then you should check the frame size and warnthe user about unsupported content where possible. The platform videocontrollers generally just provide their best effort to play whatever isrequested.Similarly, for the selection of appropriate bit rates, you need to test yourapplications with all the bearers you expect to support.
The maximumEXAMPLES AND TROUBLESHOOTING103bit rates supported on a bearer are rarely achieved in practice (seeTable 4.2 in Section 4.7 for some realistic values for common bearers).If you attempt to use too high a bit rate, then either the streaming serverautomatically adapts, resulting in visible loss of quality, or the video maystall, re-buffer or stop.5Multimedia Framework: Audio5.1 IntroductionThis chapter is about adding features to your Symbian OS applicationsto play or record audio. As we stated in Chapter 2, there is a wholesubsystem dedicated to playing audio files, clips and buffers; it can bequite daunting at first – especially deciding which of the various APIclasses is the most suitable.The sample code quoted in this chapter is available in the Symbian Developer Library documentation (found in your SDK or online atdeveloper.symbian.com).
You’ll find it in the Symbian OS Guide, in theMultimedia section (there are a set of useful ‘How to. . .’ pages which givesample code and sequence diagrams for each task). We also recommendthat you take a look at the sample code that accompanies two of our mostrecent books. Check out the code for Chapter 4 of Games on Symbian OSby Jo Stichbury et al. (2008) (developer.symbian.com/gamesbook ) andthe code for Symbian C++ for Mobile Phones Volume 3 by Richard Harrison & Mark Shackman (2007) (developer.symbian.com/main/documentation/books/books files/scmp v3/index.jsp).
For each book, the sourcecode can be downloaded from the link near the bottom right corner ofthe page. Feel free to re-use and extend it – and if you want to shareyour updates, you can post them on the wiki page for this book atdeveloper.symbian.com/multimediabook wikipage.In this chapter, we go through the classes in turn, looking at what theclasses are used for or how they mainly are used, and also a bit on whatnot to try. Before we do this, it might be worth just noting the main APIsfor reference. They are shown in Figure 5.1.106MULTIMEDIA FRAMEWORK: AUDIOClient UtilityAPIsAudio StreamAPIsControllersDevSoundFigure 5.1The Symbian OS audio subsystemThis is a very simplified view compared to what we show in thearchitectural pictures, but it shows how the various APIs are organized.Roughly speaking, there are two groups:• Audio client utilities work on files and the like. Most importantly,they are implemented using ‘controllers’ – special plug-ins that run intheir own threads.
Examples are CMdaAudioPlayerUtility andCMdaAudioRecorderUtility.1• Audio stream utilities work primarily with buffers of data and relyon the lower-level adaptation (DevSound, and below) for support fordifferent formats. Examples include CMdaAudioInputStream andCMdaAudioOutputStream.2There is a third group that does not naturally fit into these categories.For example, CMdaAudioToneUtility plays files, but the implementation is somewhat different and internally it has more in common withCMdaAudioOutputStream than, say, CMdaAudioPlayerUtility.We usually group it with the stream utilities, but that is for internalreasons and from an API view it is perhaps best viewed as a special case.DevSound is a lower-level API that is used, behind the scenes, bythe others. It represents the ‘audio adaptation’, which is the level on thedevice hardware – for example, it encapsulates hardware-specific codecsand the various sound drivers themselves.
An applications developer canlargely ignore this – just take it as read that the code at this layer can vary1To use these utilities, include MdaAudioSamplePlayer.h or MdaAudioSampleEditor.h and link against mediaclientaudio.lib.2 To use these, include MdaAudioInputStream.h or MdaAudioOutputStream.h respectively and link against mediaclientaudioinputstream.lib ormediaclientaudiostream.lib.AUDIO INPUT AND OUTPUT STREAMS107tremendously from one smartphone model to the next.
Symbian OS isdesigned to support hardware-accelerated audio encoding and decodingbut you need not really consider it – it all depends on how the variousplug-ins are implemented.Technically some of the adaptation exists at the controller level – thatis, different devices have different audio plug-ins. This should not concernyou much, except to accept that the file formats supported from one modelto the next vary. However, we look at how the code can be written in aportable manner that does not place too much reliance on the specificsof implementation3 – you can write code that is highly dependent on thespecifics of a particular device but this should usually only be used bytest code.5.2 Audio Input and Output StreamsThese simple APIs are about playing or storing descriptors full of audiodata.
They are very simple APIs and are effectively thin layers overDevSound (see Section 5.7). There is no separate thread and the streamsare more limited in the formats supported than the client utilities describedabove.As APIs, audio input and output streams are fairly simple, related tothe recording and playing of audio data to or from descriptor buffers.In describing them, it is perhaps preferable to state what they are not:they are not an alternative to the client utilities and they do not directlydeal with the same sort of audio data. Audio client utilities generallydeal with formatted audio files (also known as ‘wrapped audio’), wherethe audio data is held in an audio file, such as a WAV file, along withheaders and other extra information. The code that deals with these fileshas to know how to process the headers and to jump, on request, to theaudio data itself.
The audio input and output streams, on the other hand,deal just with the audio data itself, for example, PCM, or similar, data.In some ways, playing and recording PCM data is what they are bestsuited to; theoretically they can be used with any format supported bythe DevSound level, but sometimes formats need additional setup callsusing private or non-portable APIs. It is perhaps best to stick to PCM – beit 8- or 16-bit – as it is the most useful.The other thing to note is that these calls are not primarily intendedfor ‘streaming data’, as in playing streamed data from the web.
There isnothing to stop that use, specifically, except that for much of the timethe format is not appropriate – if the downloaded data is PCM, it wouldwork; if it is WAV, AAC or similar, then it won’t – at least, not without alot of additional work in your application.3For more advice on this subject, see Chapter 8.108MULTIMEDIA FRAMEWORK: AUDIOIn practice, these APIs mainly cover two key use cases and a third to alesser extent:• An application contains its own audio engine (typically portable code)that processes files, etc.
and contains its own codecs, producing oraccepting PCM data at the lower level. This is a typical scenariowhere you are porting code from other systems. Audio input andoutput streams are the recommended approach at the lowest level.• Your program generates audio data or needs to process it. This is inmany ways similar to the previous category but it typically relates tothe function and not because you have existing code – that is, you’dwrite new code this way too.• Your program plays ‘raw’ audio data from files or resources. This ismore portably done using CMdaAudioPlayerUtility but usingCMdaAudioOutputStream uses fewer run-time resources and startsmore quickly.To a large extent, CMdaAudioInputStream is the mirror image, andagain primarily covers the first two use cases – it can also be used to fillyour own buffers with ‘raw’ audio data, encoded but unwrapped.5.2.1 ExampleThis example uses an audio input stream and an output stream to recordsome data and then play it back.
The example does not assume it is beingrun from a GUI environment, but that would be the standard use case. Itis structured as an ‘engine’ with an associated API and callback, and canthus be called from any C++ code running with an active scheduler andusing the usual Symbian OS approach (TRAP–leave) for exceptions.The code roughly breaks into two – input and output – but first let’slook at the ‘common’ code: the headers and constructors.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
