Audio (video) - Kindle. Getting it up and running, Code level.

[geekmaster]

I am trying to static link alsa from source now, partially using instructions from here:
http://omappedia.org/wiki/ALSA_Setup

I need a libasound.a to static link my apps.

Hmm... Getting this error during this command:
arm-linux-gcc --static -o tones tones.c -lasound -lm -lpthread -ldl

warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

Apparently my libasound and libdl need different glibc versions than I am using now to static link them to the same app.

The reason I want static linking is so my app runs on firmware 2.5.8 through 5.1.0 kindles.

When I leave out the --static in the above command, it compiles. When running it on the K3 I get this error:

./tones: relocation error: ./tones: symbol snd_pcm_hw_params_set_rate_resample, version ALSA_1.0.9 not defined in file libasound.so.2 with link time reference

but when I run it on my K5 I get this error:

./tones: /usr/lib/libasound.so.2: version `ALSA_1.0.9' not found (required by ./tones)

What good is static linking if it still dynamically loads libraries? I read about an alsa patch to get real static linking. Now I will have to go track that down...

I get confused easily by these library version issues. That is one reason I like monolithic C programs with no library dependencies.

[NiLuJe]

@geekmaster: That looks like a more recent ALSA header/lib on your compile env than on the Kindle. (ie. it pulled symbols from ALSA 1.0.9 because they were there in your env, but the version bundled on the Kindle is older than that, or mangled, or built without symbol versioning).

Try a static build configured with --without-libdl --without-versioned

[geekmaster]

I copied the one I just built earlier when I built libasound.a. When in the same K5 folder as the tones program, it actually runs, but reports a playback open error (no such device or address), just like twobob's compile did on the K5 with its original libs.

I will try it on my K3 now WITH the .so file...

EDIT: No, same error on K3 as K5:

[root@kindle us]# ./tones
Playback device is hw:0,0
Stream parameters are 44100Hz, S16_LE, 2 channels
Sine wave rate is 440.0000Hz
Using transfer method: write
ALSA lib dlmisc.c:246:(snd1_dlobj_cache_get) symbol _snd_pcm_hw_open is not defined inside [builtin]
Playback open error: No such device or address
[root@kindle us]#

So with the libasound.so copied to the run folder, it runs a bit before bailing...

FYI, my CodeSourcery is "2010q1-202", which works great for my monolithic demos.

So, do I need to install an OLDER CodeSourcery then? Which one will build apps that run on 2.5.8 through 5.1.0 firmware? This mismatch is WHY I want a static linked app with no (uncommon) library dependencies. I do NOT want separate compiled versions for different kindle firmwares...

P.S. I built the latest alsa 1.0.25... Do I need a version older than 1.0.9 then? I do not enjoy dealing with this stuff, and this is supposed to be a HOBBY... It is so much easier to pipe STDOUT to aplay (but much less elegant).

[NiLuJe]

Nah, the symbol versioning on the bundled ALSA is very odd... They have literally nearly every minor version in the 'new' (ie. 1.0.x) API versioned... While stuff built with symbol versioning with ALSA 1.0.25/git only versions the very, very old 0.9 API...

(Also, the symbol names end up being humongous, readelf -W is my new friend!).

So, yeah, either try a static 1.0.25 build without libdl/versioning, or try a versioned build from the exact same build as on the target Kindle (which kinda defeats your purpose).

(I'm not all up to snuff on ELF symbol versioning, but that does look like the most likely culprit, with weird reloc failures at runtime like that...)

[geekmaster]

Originally Posted by NiLuJe

@geekmaster: That looks like a more recent ALSA header/lib on your compile env than on the Kindle. (ie. it pulled symbols from ALSA 1.0.9 because they were there in your env, but the version bundled on the Kindle is older than that, or mangled, or built without symbol versioning).

I just tried building it adding your options. I get this error:

../src/.libs/libasound.a(control.o): In function `snd_ctl_open_conf':
control.c:(.text+0x2584): undefined reference to `snd_control_open_symbols'
../src/.libs/libasound.a(pcm.o): In function `snd_pcm_open_conf':
pcm.c:(.text+0x3a1c): undefined reference to `snd_pcm_open_symbols'

Here is my configure command line:

CC=arm-none-linux-gnueabi-gcc ./configure --target=arm-linux --host=i686-linux --disable-python --enable-static --disable-shared --without-libdl --without-versioned

[NiLuJe]

Yup, checked ALSA 1.0.12 (which looks like the one used on the K3), and the linking script indeed does the same kind of versioning on the 1.0 API that the newer versions don't do anymore... That's fun. -_-"

EDIT: Apparently, it was a bug ;-)

From what I gather, they use libdl/dlsym/a dlsym wrapper because they default to dynamically loading the plugins, to avoid the overhead of having the dynamic loader do a full lookup for every plugin when you usually only need a small part of them in your processing chain, I think... That ends up being funny to do with only static libraries when you need to handle symbol versioning on top of it. (Take that with a grain of salt, I didn't look too deeply into it, and that's mostly way-over-my-head ELF stuff ;p).

[geekmaster]

Originally Posted by NiLuJe

Yup, checked ALSA 1.0.12 (which look like the one used on the K3), and the linking script indeed does the same kind of versioning on the 1.0 API that the newer versions don't do anymore... That's fun. -_-"

I hate using libraries (i.e. "other people's" code)! Grr... Bashing the bare metal is so much more satisfying... Perhaps NIH is a component of OCD? Poking I/O controller hardware registers is more my "cup of tea".

[NiLuJe]

@geekmaster: Sorry, didn't see your edit sooner

It (1.0.25) builds okay here with

./configure --prefix=${TC_BUILD_DIR} --host=${CROSS_TC} --enable-shared=no --enable-static=yes --without-libdl --without-versioned --disable-python --disable-resmgr --disable-dependency-tracking --without-debug --disable-alisp --enable-seq

:?

(Where CROSS_TC is my X-TC triplet, arm-kindle-linux-gnueabi)

And readelf confirms that the _symbols stuff from a nonpic (static) build is there.
Stupid question: did you make sure you re-ran the whole configure/make enchilada from a clean tree (make distclean)? Also, not sure about your whole CC/host/target stuff, usually, a correct --host is enough with autotools, I very rarely have to override CC manually, and that's usually only when a project doesn't use a real buildsystem .

[twobob]

Curse you, International timezone. Sorry I missed the messages.

[geekmaster]

Originally Posted by NiLuJe

...
It (1.0.25) builds okay here with

./configure --prefix=${TC_BUILD_DIR} --host=${CROSS_TC} --enable-shared=no --enable-static=yes --without-libdl --without-versioned --disable-python --disable-resmgr --disable-dependency-tracking --without-debug --disable-alisp --enable-seq

:?
...
Stupid question: did you make sure you re-ran the whole configure/make enchilada from a clean tree (make distclean)? Also, not sure about your whole CC/host/target stuff, usually, a correct --host is enough with autotools, I very rarely have to override CC manually, and that's usually only when a project doesn't use a real buildsystem .

As mentioned in a previous post, I followed the instructions (with static options added) here: http://omappedia.org/wiki/ALSA_Setup

It was building successfully when I added your options, but it only runs successfully (up to the point that it fails) when I copy the .so file to the folder containing the tones program.

I did a "make clean", but not a "make distclean".

What I want is a program that runs on all the kindle models without recompiling. In that case of eink, this took some extra manipulation (especially with the incompatible eink headers for 5.0.x and 5.1.x firmware).

[geekmaster]

Okay, instead of using the latest source code, I suppose I should use the PATCHED 1.0.13 version from the 2.5.8 and 3.3 GPL sourcecode.

Do I ALSO need another version for 5.x? The one in the 5.x GPL source code is 1.0.22, and appears to be UNPATCHED.

And 4.x does not even HAVE alsa code, so if I wanted to PWM sound out the power LEDs (green and yellow, for stereo), I do not know what alsa version to use.

Is there an alsa lib that I can static build which will work on all the kindles (except 4.x)?

---

With my current knowledge base, it would be easier (for me) to just pipe raw audio to the aplay app (not much different from calling eips to do eink updates), like I already did when piping from ffmpeg.

If we really DO need multiple app versions to work with different installed alsa lib version, piping to aplay would be a lot more "cross platform". Futzing with libraries hurts my brain, and a kindle OTA update could potentially break my sound apps.

[geekmaster]

I have alsa lib 1.0.25 (the latest) working on K3 and K5, with static linking (and now dynamic linking too).

The key was disabling everything I was not using (especial hwdep) in the configure options. The tones program compile needed different linked libs than my earlier attempt.

Here are my alsa build commands:

CC=arm-none-linux-gnueabi-gcc ./configure --target=arm-linux --host=i686-linux --disable-python --enable-static --disable-shared --without-libdl --without-versioned --disable-hwdep --disable-rawmidi
make
cp src/.libs/libasound.* /home/user/CodeSourcery/2010q1-202/arm-none-linux-gnueabi/libc/usr/lib/

Here is my gcc cross-compile command (static build) for tones:

arm-linux-gcc --static -o tones tones.c -lasound -lpthread -lm -lrt

EDIT: I just rebuilt tones without the "--static" option. The resulting tones program was MUCH smaller, and still works on both the K3 and K5. It is attached below. Enjoy! And thanks twobob -- now I can merge this into my code to make it annoying to other people in the room too. And this was built from the newest available stable alsa lib source code too (using CodeSourcery 2010q1-202).

EDIT2: It works on my DX (white) as well. Testing it on my K4s will be a bit harder, I'm afraid.

EDIT3: Another option for K4 sound (currently being used on the Nook Simple Touch) is to activate USB host mode and plug in a USB "sound card". We could borrow from the NST rooting project.

@twobob: you probably need to configure with "--disable-hwdep" to get the k5 fatal error to go away on your build (like I used). I also removed midi support. If you want to reconfigure the serial port to support midi, go for it. I sold my Yamaha DX7 long ago when I needed money, so I don't need midi.

[NiLuJe]

@geekmaster: Great! Glad you got to the bottom of this . It indeed looks like hwdep support is not really completely there on the K5, but this is starting to make my head hurt trying to understand the twist and turns it's doing... ^^

[twobob]

Originally Posted by geekmaster

I have alsa lib 1.0.25 (the latest) working on K3 and K5, with static linking (and now dynamic linking too).

The key was disabling everything I was not using (especial hwdep) in the configure options. The tones program compile needed different linked libs than my earlier attempt.

Here are my alsa build commands:

CC=arm-none-linux-gnueabi-gcc ./configure --target=arm-linux --host=i686-linux --disable-python --enable-static --disable-shared --without-libdl --without-versioned --disable-hwdep --disable-rawmidi
make
cp src/.libs/libasound.* /home/user/CodeSourcery/2010q1-202/arm-none-linux-gnueabi/libc/usr/lib/

Here is my gcc cross-compile command (static build) for tones:

arm-linux-gcc --static -o tones tones.c -lasound -lpthread -lm -lrt

EDIT: I just rebuilt tones without the "--static" option. The resulting tones program was MUCH smaller, and still works on both the K3 and K5. It is attached below. Enjoy! And thanks twobob -- now I can merge this into my code to make it annoying to other people in the room too. And this was built from the newest available stable alsa lib source code too (using CodeSourcery 2010q1-202).

EDIT2: It works on my DX (white) as well. Testing it on my K4s will be a bit harder, I'm afraid.

EDIT3: Another option for K4 sound (currently being used on the Nook Simple Touch) is to activate USB host mode and plug in a USB "sound card". We could borrow from the NST rooting project.

@twobob: you probably need to configure with "--disable-hwdep" to get the k5 fatal error to go away on your build (like I used). I also removed midi support. If you want to reconfigure the serial port to support midi, go for it. I sold my Yamaha DX7 long ago when I needed money, so I don't need midi.

Excellent Info. Much appreciated, sadly my machine will NOT build x-compiled static, it hates me. perhaps I should give it another go.

I have been working on getting simultaneous playback in one application a reality...

[root@kindle video]# zcat bunny.raw.gz |./Kradle -m write -r 16000 -w 16000.wav

Now does indeed preload a wav, monitor stdin for the video, play audio through the void gmplay4(void) method as part of the video loop.

I'm just fiddling around with buffers to skip the glitching.

All round good day. - True not a complete solution and it requires two seperate files for right now, (the raw and the wav) but hey, I'm a guitar player. It's getting there.

[geekmaster]

Originally Posted by twobob

Excellent Info. Much appreciated, sadly my machine will NOT build x-compiled static, it hates me. perhaps I should give it another go.

No need for static, now that it works both ways on all my kindles (that have sound support).

When you get the audio buffer to stop glitching, I want to see the Kradle source code. The place to interleave audio into a gmv file is in the raw2gmv program.

I have enough working now that I can build your tones program, after building and adding alsa lib (dynamic and static) to my cross-tools. Next step is to mod tones to do something "less annoying" (and add in some video demo code too).

BTW, it took me a bit to realize that I had to hit the power button on my DX before the Vol- button would work, when tones was playing TOO DAMN LOUD!

This gives us another reason to get USB host mode working, so we can stick a $3 USB sound stick on a K4 to give it sound support too (just like the XDA folks did for the Nook Simple Touch). Adding a USB keyboard to a K4 would not be too shabby either.