Sometimes I have trouble focusing on one task. So as you might have guessed, the internet radio plugin project took a hit this week. I couldn't get a pipe, named or anonymous, to push the internet samples into the guts of rockbox. Something, perhaps the rockbox buffering, perhaps my incompetence, always seemed to get the pipe closed before I got any data out of it. So I went to plan B. Just use rockbox as the GUI to select a pls file and pass its URL on to mpg123 or mplayer running in a slave process. That was a quick failure on IZ2S when I discovered the IZ2S ALSA lib is busted and I've been unwittingly using the OSS compatibility layer instead. Maybe that could explain the performance differences between the Z2lite and IZ2S versions? I haven't got a clue. But now I had a new mission to build a working ALSA libasound for IZ2S because with the OSS drivers there's no way to get rockbox and another player to share access to the sound device. I think it bypasses the mixer, or something like that in sound system jargon.
Now as you might have guessed, this has not gone well. The IZ2S scratch build environment appeared to come preloaded with an ALSA lib version 1.0.18 to build with, but as I discovered this was broken. Apparently it was compiled in a buildroot environment and then pasted into the scratchbox env without testing. When I tried to build some test programs they failed to link because the ALSA lib was built using an incompatible floating point option. It used FVP floating point, but the scratchbox compiler was using FPA. You'd think this would be simple as the xscale processor in the zipit doesn't have any floating point support, but what it really means is it just has to be done by some sort of software.
This led me to various history lessons on the deepest dark secrets of the wide variety of ARM floating point options, and on a quest for the mysterious missing libfloat which promised to let me at least link the test programs. I don't think there's any chance it'll run because the VFP and FPA formats are word swapped. Anyhow, I discovered that while there are some working VFP static linked programs in IZ2S, the static linked (and functional) ALSA utilities are not among them. They were built with FPA floating point and ALSA 1.0.21 in some unknown build environment.
Ok, so maybe I could just build a new ALSA lib in the scratchbox build environment. That's worked pretty well for all the other shared libs I've built. But no. It doesn't work. Deep in the bowels of the libasound it loses it's way "refining the config" and eventually decides it's "unable to find an usable client format". It looks like part of the trouble is with the sample rates. It should report something like 8k, 16k, 48k, 96k, 11.025k, 22.05k, 44.1k as available, but it only reports 8k and 96k. Hmmm, could this be a floating point problem?
At this point I'm pretty sure the floating implementation in the scratchbox build environment is broken. It uses gcc 4.1.1 and bugs like this one lead me to believe it's the compiler or uclibc that's doing me in. Remember way back when I couldn't get doubles to work in night sky, so I eventually replaced them all with floats and it worked. The ALSA lib code has only a smattering of doubles so I may try the same approach. But first I might try building the much smaller SALSA library which is suggested for embedded systems by the ALSA folks.
If this all fails I suppose I can return to the buildroot setup and try to build static ALSA, SDL, and pthread libs so I can try a static linked rockbox executable with VFP floating point on IZ2S. That doesn't sound like very much fun though.
Meanwhile, I really think I'm gonna need a debugger to get to the bottom of this. Perhaps I should try to build gdbserver...
No comments:
Post a Comment