Android SurfaceView: can be used for media or direct access, but not for both.

That is, if you have an instance of SurfaceView, you can use it for video/camera, or use it for direct access as a buffer, but you cannot reuse it for media after you already accessed it through either ANativeWindow API or any other internal ways.

The reason is in ASOP code Surface.cpp. Surface connected to CPU if it once got locked, which is a necessary step to access its internal buffer. But it only got disconnected in  destructor. On other side, if you bind the Surface to media, it checks the connection status and return an error when it found it has already been connected to CPU.

So, if you need a SurfaceView for both purpose, you have to destroy the old, assuming it is for direct access, and create a new one for media.

So many traps there…

Simply, a .so compiled by android ndk r9 gcc 4.6 crashed on loading in function __check_for_sync8_kernelhelper.

After looking up the issue in Google, I found this issue has been reported to Google: https://code.google.com/p/android/issues/detail?id=58476. Unfortunately no solution at present.

Basically it is an libgcc issue depending on linux kernel version. Lower kernel version lacks the symbol that libgcc in 4.6 or higher needs. For example, the Galaxy Nexus I am just testing app on.

 

So,

1) Avoid using 64bit atomic operation built in gcc, if you can control everything in your codes.

2) Using gcc 4.4.3. For ndk r9 there is a legacy toolchain package in a separated download link.

Why so many latencies in BB10 audio playback? Why we always get underrun in audio data feeds?

They are two faces of one same issue.

If you started coding audio playback from reading PlayWav sample in BlackBerry’s github repository, you will find there are long latencies in audio playback, that is, about 5s after you fed data, you can hear the sound. But why? BB10 uses ALSA’s libasound as its audio API but the documentation and description are very little. So after many changes here and there, many trials and inspections, I got what controlled the latency.

snd_pcm_channel_params_t.buf.block.frag_max;

In PlayWav sample, this field is set to -1, which returned a large number in it from call of snd_pcm_plugin_params(). So we can set this field to a small number to reduce the latency. Indeed it is said that RIM recommends 5 but I don’t know whether it is true and I cannot remember where I found it.

Anyway, a number like 3 or 5 can exactly reduce latency to some small value so that our ears cannot find it. But another strange behavior occurs then: we got UNDERRUN frequently. At that time, if we set snd_pcm_channel_params_t.stop_mode to SND_PCM_STOP_STOP, the playing back stopped after a short time interval; if we set snd_pcm_channel_params_t.stop_mode to SND_PCM_STOP_ROLLOVER, the playback will repeats data in a few last buffers.

The latter issue is due to thread priority. QNX’s io-audio drivers runs playing back in very high priority so it is very easy to make your data UNDERRUN if you just run your data feed thread in a normal priority. In some discussion somebody recommends set data feed thread to 50 and in some other codes the value was set to 18 or so.

Conclusion: to make audio playback smoothly and easily, 1) set frag_max to 5 or another small value but too small may cause UNDERRUN issue. The field controlled data buffering – yes, it equals to audio latency on other side – in implementation of audio playbacks. 2) raise your data feed thread priority to some higher value. Normal thread runs on 10 and audio playback thread runs on a higher priority. Set to higher to avoid data UNDERRUN.

 

iOS7: We cannot modify UIAlertView directly now.

From iPhoneOS 1 to 6, each experienced iOS programmer knows how to modify UIAlertView for appearance customization. For example, to add some UI elements like UILabel or a secure UITextField for password input, etc. One of our little tool keyOne used this trick.

But this doesn’t work in recent iOS7 beta. The reason is simple after checking view hierarchy in debugger. This is keyWindow when a UIAlertView popped up:

(lldb) po [[UIApplication sharedApplication] keyWindow]
<_UIModalItemHostingWindow: 0xb2dba70; frame = (0 0; 320 568); gestureRecognizers = <NSArray: 0xb2d5f20>; layer = <UIWindowLayer: 0xb2dbb50>>

and a view for alert exactly

(lldb) po [[[[[UIApplication sharedApplication] keyWindow] subviews] objectAtIndex:1] subviews]
<__NSArrayM 0xc975e80>(
<UIView: 0xb2e83a0; frame = (0 0; 320 568); layer = <CALayer: 0xb2e8770>>,
<_UIModalItemRepresentationView: 0xb2e5de0; frame = (25 184; 270 200); layer = <CALayer: 0xb2e5da0>>
)

The UIAlertView returned to caller is a stub only

lldb) po alertView
<PasswordPrompt: 0xb2c7f80; baseClass = UIAlertView; frame = (0 0; 0 0); opaque = NO; layer = <CALayer: 0xb2a1cc0>>

The view has zero size so we certainly cannot customize it.

 

QNX’s problem 1: Mix C and C++ code.

It looks like some standard C header files like math.h in QNX toolchain contains C++ elements around by #ifdef __cplusplus preprocessor directives. That will bring some troubles when you need to mix C and C++ in one project.

Let’s see an example. Assume we have a C header file c.h and a C source file c.c, like below

c.h

#ifndef __C_H__
#define __C_H__
#include <stdint.h>
#include <math.h>
struct struct_c {
 int32_t dummy_field;
};
int func_c(struct struct_c * c);
#endif // __C_H__

c.c

#include <stdio.h>
extern "C" {
 #include "c.h"
}
int main()
{
 struct struct_c c;
 c.dummy_field = 1;
return printf("func_c() = %d\n", func_c(&c));
}

Compile them into a shared library libccc.so:

mbp17:qnx_header_test lee$ /Applications/bbndk/host_10_0_9_52/darwin/x86/usr/bin/ntoarmv7-gcc -c c.c
mbp17:qnx_header_test lee$ /Applications/bbndk/host_10_0_9_52/darwin/x86/usr/bin/ntoarmv7-gcc -shared c.o -o libccc.so
mbp17:qnx_header_test lee$ ls -l libccc.so
-rwxr-xr-x 1 lee staff 4725 11 1 11:36 libccc.so

That’s OK.

Now we have another C++ file named cc.cpp

#include <stdio.h>
extern "C" {
 #include "c.h"
}
int main()
{
 struct struct_c c;
 c.dummy_field = 1;
return printf("func_c() = %d\n", func_c(&c));
}

It is very simple. Let’s try to compile it. We got tons of errors! Some listed as below:

mbp17:qnx_header_test lee$ /Applications/bbndk/host_10_0_9_52/darwin/x86/usr/bin/ntoarmv7-g++ -c cc.cpp 2>&1 | more
In file included from /Applications/bbndk/target_10_0_9_386/qnx6//usr/include/math.h:4:0,
 from c.h:5,
 from cc.cpp:4:
/Applications/bbndk/target_10_0_9_386/qnx6//usr/include/xtgmath.h:116:1: error: template with C linkage
/Applications/bbndk/target_10_0_9_386/qnx6//usr/include/xtgmath.h:150:1: error: template with C linkage
/Applications/bbndk/target_10_0_9_386/qnx6//usr/include/xtgmath.h:157:1: error: template with C linkage
/Applications/bbndk/target_10_0_9_386/qnx6//usr/include/xtgmath.h:163:1: error: template specialization with C linkage
/Applications/bbndk/target_10_0_9_386/qnx6//usr/include/xtgmath.h:200:1: error: template with C linkage
/Applications/bbndk/target_10_0_9_386/qnx6//usr/include/xtgmath.h:207:1: error: template specialization with C linkage
/Applications/bbndk/target_10_0_9_386/qnx6//usr/include/xtgmath.h:212:1: error: template specialization with C linkage
/Applications/bbndk/target_10_0_9_386/qnx6//usr/include/xtgmath.h:218:1: error: template with C linkage
/Applications/bbndk/target_10_0_9_386/qnx6//usr/include/xtgmath.h:224:1: error: template specialization with C linkage
/Applications/bbndk/target_10_0_9_386/qnx6//usr/include/xtgmath.h:229:1: error: template specialization with C linkage
/Applications/bbndk/target_10_0_9_386/qnx6//usr/include/xtgmath.h:234:1: error: template specialization with C linkage
/Applications/bbndk/target_10_0_9_386/qnx6//usr/include/xtgmath.h:239:1: error: template specialization with C linkage
/Applications/bbndk/target_10_0_9_386/qnx6//usr/include/xtgmath.h:245:1: error: template with C linkage
/Applications/bbndk/target_10_0_9_386/qnx6//usr/include/xtgmath.h:251:1: error: template specialization with C linkage
/Applications/bbndk/target_10_0_9_386/qnx6//usr/include/xtgmath.h:256:1: error: template specialization with C linkage
I

Check error messages. Obviously math.h includes xtgmath.h internally. In latter some C++ template definitions are there around #ifdef __cplusplus directives. But in compiler’s view, though we wrapped #include “c.h” with extern “C” – it is necessary for linking, __cplusplus is still defined for C++ program. So, templates were incorrectly included into a pure C linkage enviroment.

 

 

It is just like walking on a steel wire over the deep…

…to play with Apple’s famous Xcode and LLVM compiler sets, especially for ARM instead of x64 series.

So, somebody may ask: What beats you on the face _again_?

This time Apple decided to use clang 4.0 from LLVM 3.1svn in its latest Xcode 4.4, which was just pushed out with Mountain Lion some days ago. That’s OK. Generally most of things still work, most of codes still got compiled. But, suddenly I found an assembling error on my one .S file: invalid instruction ‘ldmltfd’. It is not the exact error message but you know the meaning is it.

The .S file can be compiled/assembled without any problem by previous Xcode version, if my memory is still correct, at least by any version of Xcode 4.x and its toolchains, from apple-gcc-4.2 to clang. And, ‘ldmltfd’ is a valid ARM instruction. So it should be another LLVM/clang’s issue. Indeed I must not feel surprising since I already encountered many before.

But I must have a work around otherwise I must return back to Xcode 4.3.x, which doesn’t have official ML support in it. Though I think it is not a big problem, the uninstall and install still take much time. OK. Let’s see.

After adding ‘-v’ to compiling option the output shows clang called itself with ‘-cc1as’ after executed preprocessing. ‘clang -cc1as –help’ shows this call invokes clang’s integrated assembler to assemble the source instead of invoking external ‘as’ program. Fortunately ‘clang’ in my Lion system is still an old version (3.1 from LLVM3.1svn) so I can check it over the source with ‘-v’ option and found it invokes external assembler.

The issue is clear now. Apple guys or LLVM guys or guys having both roles thought clang’s integrated assembler is stable and complete enough. They released this version of clang with integrated assembler set as default behavior in Xcode 4.4. I am just this unlucky man stepping on the mines.

Solution is always simple as long as clang permitted us disable its integrated assembler. Adding ‘-no-integrated-as‘ to each .S file solved the issue, but it still took me about 1 hour to look for the cause and about half an hour to write this blog.

 

Updated gas-preprocessor to handle clang’s issue related to -g option

clang included in Xcode 4.3.x (LLVM 3.1) has an odd issue when it is used with gas-preprocessor.

As you may know, gas-preprocessor adds “-S” to compiler’s command line to generate assembler source, does some preprocessing on it, then invokes compiler again. The compiler then invokes assembler to create final objective code. Here, compiler is clang and assembler is apple as.

If  a “-g” is specified in clang’s command line, clang will generate dwarf-2 debug information directives into assembler source. When clang gets invoked again, it will also take “-g” into apple as’s command line options. Unfortunately, as declines those debug information directives, including .file and .loc, if it is iovoked with “-g”.

So, I have to add a hack into gas-preprocessor. If -g is in command line, eliminate it in 2nd compiler invocation.

See latest commit in https://github.com/hollylee/gas-preprocessor