Present Perfect

Today I took the time to fix an elusive off-by-one bug in cdrdao. I had to dive into the code quite a bit and I'm no C++ expert, but I figured out the bug in the end.

Basically, CD's put some information in the Q channel. This is a channel that has 16 bytes of information per CD frame (with 75 frames to a second). Among other things, that channel stores track and index number, the relative time (for display in a cd player), and the absolute time on the disc.

Pre-gaps have the relative time counting down; so the code detects a pre-gap as the point where a track goes up by one and index resets to 0. Then it stores the pre-gap length as whatever the relative time is at that point (which on disc is a positive nummer that should be displayed as a negative, and counts back). On some discs this counts back to 00:00:00, and on some it counts back to 00:00:01. The next track then starts at index 01 with 00:00:00 as the relative offset.

In the case of counting down to 00:00:00, the pre-gap is actually one frame longer than cdrdao calculates in that case. That took a while to figure out, basically by ripping a bunch of different discs and comparing to Exact Audio Copy.

Here's the bug report , and here's the patch.

This also made me realize that I have made patches to over 30 projects. Maybe it's time to trawl through those directories and follow up on some of them...

With this bug out of the way, I should gear up for a first morituri release.

I have one CD that troubles me though - José Gonzalez's first. EAC thinks it has a 7 frame pre-gap on track 3 (on two different machines), while cdrdao can't find anything there, and the Q-channel info doesn't seem to have a pre-gap either. All I can see is a lot more CRC errors than usual...

Today I took the time to fix an elusive off-by-one bug in cdrdao. I had to dive into the code quite a bit and I'm no C++ expert, but I...

I subscribe to the dream. I think a lot of features PulseAudio brings to the table are long overdue and very welcome. I even manage to be amused at Lennart's abrasiveness when it comes to defending the software he writes (though it might help that I know the guy). So I have the right mind set, which is why I persevere.

But one thing PulseAudio definitely lacks is transparency. Too much of it feels like black magic. I certainly pretend to know more about Linux audio than the average user, and even then I'm mystified by simple things as 'why does pulseaudio sometimes not seem to be running ? What is responsible for starting it at login time ? Why doesn't it get started when some app starts playing sound ? How do I figure out why sound doesn't work for this application ?'

Today I was reminded again as I ran into some problems with skype (bug filed). PulseAudio asserts and goes away probably because of something Skype does wrong (although one could argue that PulseAudio shouldn't break down completely because of one bad client).

The bug itself is not the point of this post. What I'm lacking in PulseAudio is a way in to understand problems and help create good bug reports. A PulseAudio debugging guide would be excellent to have; one that would tell me 'set up pulseaudio like this to get more info when the crash happens'. Googling doesn't find me a guide, and PulseAudio's website doesn't have one either.

Lennart, if you can give me some starter tips to provide better bug reports I'll volunteer to write up a Trac wiki guide to do the debugging and bug reporting.

No need for the haters to comment on this post - whether it's hate against Skype or PulseAudio :)

I subscribe to the dream. I think a lot of features PulseAudio brings to the table are long overdue and very welcome. I even manage to be amused at Lennart's...