1) ReseveCache=2 seems to work for me. At some point I'd somehow removed it, and emphatic wasn't very happy. Lot's of disk churning, and high CPU usage (ISTR that disk I/O is CPU bound on the empeg), resulting in a rather unresponsive empeg. I tried ReserveCache=4 too, but this seemed to have equally bad results - I guess that the player was being starved at this point.

ReserveCache=2??? I have my ReserveCache set to 64. Last I heard the player has 180 * 32k cache blocks, so I can't see how ReserveCache=2 or ReserveCache=4 does much for us. ReserveCache=64 Still seems to leave the player with enough to play with. Maybe this is your sluggishness problem? Let me know if it is so I can recommend that end users set their ReserveCache a little higher.

I do notice a little sluggishness when it first reads the lyrics, but after that things are fine on my player. In the future I may try out that libmad tag library, that might be a little less taxing than id3lib.


2) Yes, the horizontal scrolling definately still needs some work - it goes in fits and spurts too much. This is most obvious with the large font. My test track appears to be good - the timings work well in vertical mode. I wonder whether horizontal scrolling will ever be as smooth as we like, give that we are bound by the 40Hz screen rate anyway. I also wonder whether looking another line into the future might help with timing.

I think I know why you're seeing this one. There is an increment factor which gets calculated based on how long our calculated sleep time is. If it's really low, it means we need to cover a lot of screen real estate in a short amount of time. The only solution is to skip pixels, instead of moving one pixel at a time, move 2, or even 3 at a time. This only happens when things are REALLY tight, with fast lyrics or, as you mentioned, the large font. Basically, if our calculated sleep time is under 15000 microseconds, we're in trouble, so we skip two pixels per update. If the calculated sleep time is under 10000 microseconds, we skip 3.

Now, there IS a bug that I've fixed (but can't release right at this moment because I'm working on other things in the program) where that increment wasn't being reset when it should be. The result was (I think) as soon as one line in a song needed that correction, the rest of them were getting it because I wasn't resetting that increment. Well, that will be fixed in the next version. I'd be interested in hearing your subjective analysis of if this bug fix solves the problem you're seeing. (Patrick G found the bug, by the way. I need to invite him to my code reviews at work.)

emphatic needs to be better behaved with buttons. It really shouldn't keep the buttons bound during general use, and I have seen some quirkyness with the left and right buttons when lyrics have been active. (Typically a short press being translated as a long press). I know that you've mentioned wanting to make emphatic sit back more in the background. I think that the ideal solution would be to separate out the lyrics display and UI functions into 2 processes, ie emphaticd and emphatic_control. Then bind emphatic_control to the hijack menu, and bind all the buttons for menu use only. When you exit the menu (ie, emphatic_control), unbind all the buttons, and wait for selection from hijack again. I'm hoping that future versions of hijack will enable userland apps to be assigned to the Popup menus.

No can do. Reason? Fast forwards and rewinds. I need to detect them, and there's no other way except trapping the buttons. To be honest, unless I FF/REW at the very beginning of the song when disk activity is high and CPU is being taxed, I don't see too many of those short press being translated into long press problems.

If you can come up with a better way to detect FF/REW, I would be HAPPY to not bind to the player left/right buttons.

4) Slightly modified Menu options; On (exits menu leaving lyrics on), Off (exits with lyrics off), Mode, Font, Quit. Functionally I think it's identical to what you already have, but I think that it's marginally clearer - putting 'On' and 'Off' next to each other would help people to grasp the real effect that they have.

I'll put that feature request in the queue.