I still spend a little time — now and again, but not often — trying to resolve the long-standing sound issue on my Crux-driven Pentium laptop. It took me years to find out how to get any sound at all out of it, and now that it is working, I would really like to have solid, clean playback instead of skipping and pausing so frequently.
But to be honest, it doesn’t look like that’s going to happen — not like it ever really did though. I spend a little less than an hour this morning setting up mpd and ncmpc following the howto at nepherte.be. It worked for Crux as well as Arch, which came as no surprise. Technically the howto is for ncmpcpp, but ncmpc is in the Crux repos so I went with that. (For the record, building both mpd and ncmpc at 120Mhz took only about 30 minutes, plus or minus. )
Everything is working fine, but playback still sputters and pauses, much as it did in Debian with the same setup, or in Crux with mocp, or even with Orpheus — although to be honest, that last one was probably the best. mpd is particularly lightweight, but even from a cold boot with nothing but the daemon running, I still get skipping and breaks in playback, with the processor load pegged at 100 percent (according to htop).
What’s a person to do? It seems my best efforts to trim back and trim back and trim back … just aren’t enough. I suppose I could try lighter codecs — these are usually ogg files at a quality level of 7 or so — but to be honest, that adds another layer of inconvenience to the issue. If I was committed to playing back audio on this machine I suppose I could convert my measly 5Gb music collection out of oggs and into a different codec. But mp3 files are the same, plus there’s the conversion time, the transfer over the network to this machine, and ultimately the possibility that it wouldn’t help. A lot of question marks there.
I think what has happened here is that finally I have reached a point of function that has been determined by the hardware. I type to you now on a 14-year-old laptop with a huge array of up-to-date console-based programs and a modern operating system. But the machine itself — the actual hardware — probably just can’t handle the task of converting digital files into music … and since it is barely a contemporary of the MP3 trend (mentally I always equate the rise of MP3 with the advent of Winamp), I shouldn’t be surprised.
So it would appear that the practical threshhold for audio playback falls around 150 or 166Mhz or so. If you can improve upon that, please let me know, just for curiosity’s sake.
Overall, in the grand scheme of things, this doesn’t even register as a loss. It’s rare to find a machine this old any more, and even rarer to get things working to a point where audio playback is possible. But there are thousands upon thousands of machines only-slightly-faster than this one, that can handle the task without suffering. Just kick over a trash can, and pick up another one.
(And just for the record, I do have audio available — for example, centerim pings cleanly and regularly, every time a new message appears. It’s just the difference between that short burst, and a sustained seven-minute song.)
But at the same time I’d be lying if I said I wasn’t a little disappointed. It was a coup to get the thing (or its cousin, technically) running at all, and another coup to get the framebuffer working, and yet another long-awaited coup to get the audio figured out. The fact that it is working only halfheartedly now is … ironic.