Sound at 120Mhz: The good, the bad …

Now that my self-congratulation over arranging sound on a 14-year-old laptop has subsided, I can come to grips with the ugly truth: It’s only partway practical.

I had a feeling this would be the case, after getting music out of an unrelated but slightly newer 166Mhz Pentium. Sound on that machine was a bit scratchy, skipping and sputtering while the processor churned away, keeping up with the playback demands. It’s not an issue of sound quality, it’s an issue of workload, where the 120Mhz system is scrambling to keep up with that plus whatever other software or system responsibilities it has.

But like all the little problems I mention, I have a few observations and a couple of possible solutions. Never mention a problem without bringing a solution with you. 😉

First, this is definitely an issue involving system load against the processor. Normally I spin up a screen session with about seven or eight standing applications running, and bounce between them as is necessary. I might start htop, for example, but never need it except to kill a stalled telnet session, or check to see if something is still running. Or I let mc run just because it’s exceptionally handy to jump to, even though it’s not something that needs to be on continually.

The obvious answer here is to call up applications as they’re needed, rather than letting them run continually. And this is probably the most straightforward solution, seeing as if I turn off screensavers and trim away apps one at a time, the skipping slowly improves. Things are normal when only one or two other programs are running alongside the player and screen.

But screen (and this is the second thing) also seems to be involved in the dragging effects. There is a distinct difference between starting player inside screen, or starting it in a separate tty. I don’t have a specific answer to that, except to suggest that adding an application to screen requires a tiny bit more work than running it in its own virtual terminal. Which makes the solution obvious — run mocp in tty2, and go back to what I was doing in tty1 with screen.

mocp is what I prefer, but even that seems to be part of the issue. I don’t know, or can’t tell, the exact system load when comparing things so terrifically small as mocp, but it could be that the player itself is taxing. A different player might be a better idea; I have adjusted some of the settings in .moc/config and will probably research that a little more, since it is the player I like best. But there are probably lighter apps out there.

As a side note to that, mocp will detach from its playback server and continue to play music, so quitting the player (but not the server 😉 ) usually improves playback immediately. And it’s possible to send commands directly to the server from the command line, a la mpd or some other console-based players; sometimes I just dump two or three albums into moc, then quit the interface and let it run.

And if processor strain is an issue, then ALSA also becomes suspect; if something like OSS is lighter, then perhaps an entirely different subsystem is called for.

But finally, some of this is just due to hardware. A 120Mhz processor is still quite slow, by anyone’s standards (even mine). Connecting hardware is to blame too, since the staggering effect seems compounded when the drive is accessed or when the framebuffer has to refresh. Once a song is cached and playing it will improve, but between tracks or with network access underway, the problem tends to worsen. No nfs transfers while playing music, it seems.

But hardware is also the reason I pursue this quite so avidly; sound quality (without the staggering) is very, very good. And this laptop has the added bonus of a small volume control dial on the side of the frame, which means I can quickly adjust the volume up or down without having to snap between controllers or programs, just to turn down a noisy tune. Everything was easier in 1996. …

It’s always possible that a distro lighter still than Debian could display better performance, but for now I’m going to stick with this. Slitaz at 166Mhz had the same problems and Ubuntu couldn’t manage sound without most of Gnome in place, so Debian will probably stay on board for a while longer. I still have hopes for installing Crux to this machine — mostly because I have done it before and the results are fantastic — but in the meantime, I want to get some more information via Debian. It’s been a winner thus far, I’ll stick with it a little longer.

13 thoughts on “Sound at 120Mhz: The good, the bad …

  1. benj1

    The obvious solution would be to set up a dedicated music pc, of course then you would have to buy a new (to you) one 😉

    1. K.Mandla Post author

      That would be the straightforward answer to all the problems, wouldn’t it? 😉

      Joking aside, if this were a music-only machine, it would hardly have a problem. Sound quality is good, so long as the machine isn’t being overwhelmed with other stuff at the same time. I need to start playing crawl on a different computer, I guess. … 😀

    1. K.Mandla Post author

      I tried that once, but saw no real improvement. I might try lowering the priority on some of the other applications, but I don’t know if that will be of much help. If I get an answer one way or the other, I’ll post it.

  2. anonymous coward

    I wonder whether different implementations of certain codecs could bring a change. Or perhaphs different sound file formats having more/less strain on the CPU depending on the needed decoding work…

    1. K.Mandla Post author

      I had considered that too. Right now I have only ogg-format files, and I tried one mp3 as a test file and saw the same behavior. Codec options open a whole new can of worms though … low or high quality, VBR or constant, blah blah blah. I’ll have to experiment and see what works. …

  3. zenfunk

    Hm, try modfiles, they have been around since the days Amigas where popular.

    Keep it up,

  4. Pingback: A substitute audio player « Motho ke motho ka botho

  5. Xyzzy

    Hey, my 1.6GHz laptop actually has a volume wheel, that’s part of why I picked it! :o) Unfortunately, mocp isn’t a happy camper; audio skips, eats 40-90% CPU for up to a minute at a time, and at one point locked up with 98% of the CPU. Which might mean that thanks to distro changes, a console app can run as well or better on a 14-year-old computer than a 5.5-year-old one…yikes.

  6. Pingback: Thank you, Debian « Motho ke motho ka botho

  7. Pingback: Sound’s ironic « Motho ke motho ka botho

  8. Pingback: A Debian server at 150Mhz, 32Mb « Motho ke motho ka botho

  9. Pingback: Some audio success « Motho ke motho ka botho

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s