The Fugue

I often get confused about the scaling of magnitude and power spectra. I think I’ve worked it out so I’m puttin it here for my own benefit, and maybe the benefit of someone on the internet. If I’m wrong, please tell me.

Let’s take a unit-amplitude sinusoid at 100 Hz, and do a Fourier transform. If we look at the amplitude we’d get two components at 100 Hz and -100 Hz, each with amplitude 1/2. Something like this.

Now, if we do the same with a DFT we will get basically the same thing, except we’ll see the effects of discretization of course. But depending on which variation of the DFT you’re using, the magnitude of the components will be either about 1/2 or about N/2. The difference is, of course, the 1/N factor that you included or left out. In the case of the fft function in Octave (and I assume MATLAB), it’s without the 1/N factor.
max(abs(fft(x,1024)))
ans = 443.23

The power spectrum is the magnitude spectrum squared. abs(fft(x)).^2 or (abs(fft(x))/N).^2. Why would you want to square it? Well there are of course many reasons but the nature of audio signals makes most of the ones I know about moot. Furthermore the relative shape of the power spectrum and the magnitude spectrum is the same.

Try this. Take an audio signal (something more interesting than a single sinusoid) and plot the magnitude spectrum in dB, then plot the power spectrum also in dB, e.g.
plot(20*log10(abs(fft(x))))
figure
plot(20*log10(abs(fft(x)).^2))

They have a different scale, but they have the same shape. If you were doing something like peak-picking, it wouldn’t matter which you used if you’re working in dB.

As you may know, when you change the power setting on most microwaves, it doesn’t change the power output of the magnetron. It changes the duty cycle, i.e. when the magnetron is on and when it is off.

In a bout of curiousity I sat down with my microwave today and figured out exactly what those duty cycles are (you can hear when the magnetron switches on and off). My microwave apparently has a cycle period of 32 seconds. High is power level 100 and the magnetron is on all the time. Power level 50 is on 18 seconds and off 14 seconds. Power level 40 is on 16 and off 16 (which I would have guessed would be the case for power level 50). Power level 10 (the lowest setting) is on for 6 seconds and off for 26 seconds. Here’s a graph with all 10 settings:

As you can see it’s more or less linear, which is nice because it makes mental visualization easy.

Now you know.

More specifically, why do gnome-screensaver and gnome-power-manager hate me? (But that was too long for a headline.)

I have had terrible luck with these punks doing what they’re designed to do for at least 2 years now. Bugs get filed (usually someone else has filed it already), developers say “works for me” and they continue to fail to do the simple task endowed to them.

People familiar with my bashing of these two punks know that I blame it primarily on NIH syndrome and the twisted desire to remove all useful configurability from gnome. Plain vanilla DPMS has worked in X11 for a long time. xscreensaver got things ironed out too. Now gnome has to come along and redo everything because the user has too many options and the user might be able to get the screensaver to do what he actually wants.

I haven’t complained about it publicly (i.e. here on this blog) before, because I thought I was a corner case. I have a dual screen setup where one screen is a TV, mythtv and mplayer enable and disable the screensaver regularly, etc. I figured I was just pushing it too far and it broke.

But then I set up this linux box here at school. It has one screen. I don’t do anything special. I just want the screensaver to come on after N minutes and then to power off after M minutes. Even for gnome this should be an acceptable level of configuration right? And indeed the gnome-screensaver/gnome-power-manager configuration guis give me the illusion of being able to configure it this way.

But it doesn’t work. At least, not all the time. I don’t know what the problem is. I don’t even know what the pattern of misbehavior is. Sometimes it works fine. Other times the power management never kicks in. At home, the screensaver itself often doesn’t even kick in. When it does, the power management doesn’t kick in half the time.

Today I woke up to find my desktop monitor at home had stayed on all night, displaying flying toasters for the cockroaches that have showed up early to the summer party. I sighed, but I wasn’t surprised. Then I got to school and the desktop here was displaying the screensaver too. Double fail.

Please share your horror stories. Let’s raise awareness. Let’s pick a color and make ribbons. And if you happen to know how to fix these punks so that they invariably do what they’re supposed to do—for the love of electrons please send a patch to the gnome developers.

I’m sitting here having a really hard time figuring out whether I most dislike mosquitos or GNOME’s screensaver and power management.

All I want is:

1. Standard screensaver/power management stuff: you know, pretty pictures and/or turn off the monitor after a certain amount of time.
2. Allow me (user and/or script) to easily disable it, so that e.g. the screensaver doesn’t come on in the middle of a video.
3. Allow me (user and/or script) to easily enable the screensaver and/or power management instantly.
4. Don’t frickin’ lock the screen!!!1!!

Having found GNOME screensaver and power management completely incapable of doing the latter 3, even after installing and configuring Brightside, and digging through gconf-edit for the lock settings (hint: they’re there but don’t seem to work), I decided to resort to disabling them and using trusty old xset.

Now, Brightside will try to use GNOME’s power management and/or screensaver, so if you want to avoid locking as I do you have to bypass that by using custom actions. The custom action for instant DPMS standby is xset dpms force standby. The custom action for DPMS disable is xset -dpms and then when leaving that corner do xset dpms 600 1800 3600. xset, or some GNOME monster, has a bug where xset +dpms doesn’t work. It appears to work, i.e. xset q reports that DPMS was enabled, but it doesn’t actually come on unless you explicitly set them (or force standby mode).

Now, you’ll also want to run that same command at the beginning of your session, so what you probably want to do is script that (so you only have to change the timeouts in one place) and call that script from Brightside as well as put it in your session startup.

Being paranoid as I am, I took gnome power management out of my session (couldn’t find gnome-screensaver in the session—maybe it’s launched by the power manager?). But just telling them to never come on, and bypassing them in Brightside, should be sufficient.