Plasticity and Online Tone Generator now work in Firefox and Chrome

I have just uploaded new versions of Plasticity – my audio training game which may also alleviate tinnitus – and my increasingly popular Online Tone Generator – a handy tool for those times when you need your speakers to produce a specific frequency, and nothing else. The current versions use the HTML5 Web Audio API and have been tested to work on Chrome 33 and Firefox 28, at least on Windows. (They might also work on recent versions of other browsers – it’s worth a try.) Enjoy!

Web Audio API – things I learned the hard way

Firefox recently dropped support for the Mozilla Audio Data API, so I started porting my two audio-enabled Web apps (Plasticity and Online Tone Generator) to the Web Audio API, which is the W3C-blessed standard way to work with audio in the browser.

In the process, I ran into a few problems, which I thought I’d share here for the benefit of other developers making their first steps with the Web Audio API.

AudioBufferSourceNodes and OscillatorNodes are single-use entities

Suppose we want to generate two 440 Hz tones, each with a duration of 1 second, separated with a 1-second pause. This is not the way to do it:

oscillator = context.createOscillator();
oscillator.frequency.value = 440;
oscillator.connect(context.destination);
currentTime = context.currentTime;
oscillator.start(currentTime);
oscillator.stop(currentTime + 1); //stop after 1 second
oscillator.start(currentTime + 2); //resume after 2 seconds
oscillator.stop(currentTime + 3); //stop again after 3 seconds

What’s wrong? We cannot call .start() on an OscillatorNode or AudioBufferSourceNode more than once. The second call in the above code will result in an error. Both OscillatorNodes (which are used to generate simple tones) and AudioBufferSourceNodes (which are used to play back short samples like sound effects) are meant to be thrown away after each use.

Instead, we should create a separate node for every time we want to play a sound. Every time, we must also connect it to the audio graph:

oscillator = context.createOscillator();
oscillator.frequency.value = 440;
oscillator.connect(context.destination);
currentTime = context.currentTime;
oscillator.start(currentTime);
oscillator.stop(currentTime + 1);

oscillator2 = context.createOscillator(); //create 2nd oscillator
oscillator2.frequency.value = 440;
oscillator2.connect(context.destination);
oscillator2.start(currentTime + 2);
oscillator2.stop(currentTime + 3);

ChannelMergerNode inputs don’t map to channels

What do you do when you have two mono sources – like OscillatorNodes, which are always mono, or AudioBufferSourceNodes connected to a mono buffer – and you want to mix them into a stereo signal, for example, play one sample in the left channel, and the other in the right? You use a ChannelMergerNode.

A ChannelMergerNode has a number of inputs, but only one output. It takes the input audio signals and mixes them into a single multichannel signal. Sounds pretty simple, but it’s easy to fall into the trap of assuming that inputs correspond to channels in the output signal. For example, take a look at the following code, which tries to play a tone on the right channel only:

oscillatorR = context.createOscillator();
oscillatorR.frequency.value = 440;
mergerNode = context.createChannelMerger(2);
//create mergerNode with 2 inputs
mergerNode.connect(context.destination);

oscillatorR.connect(mergerNode, 0, 1);
//connect output #0 of the oscillator to input #1 of the mergerNode
//we're leaving input #0 of the mergerNode empty
currentTime = context.currentTime;
oscillatorR.start(currentTime);
oscillatorR.stop(currentTime + 2);

The result of running this code is a tone playing in both channels at the same time. Why? Because inputs of a ChannelMergerNode do not map to channels in the output signal. If an input is not connected, ChannelMergerNode will ignore it. In this case, the first input (numbered 0) is not connected. The only connected input is #1, and it has a mono signal. ChannelMerger merges all the channels on all the connected inputs into a single output. Here, it receives only a single mono signal, so it will output a mono signal, which you will hear coming from both speakers, as you always do with mono sounds.

The right way to have a sound playing only in one channel is to create a “dummy” source node and connect it to the ChannelMergerNode:

context = makeAudioContext();
oscillatorR = context.createOscillator();
oscillatorR.frequency.value = 440;
mergerNode = context.createChannelMerger(2); //create mergerNode with 2 inputs
mergerNode.connect(context.destination);

silence = context.createBufferSource();
silence.connect(mergerNode, 0, 0);
//connect dummy source to input #0 of the mergerNode
oscillatorR.connect(mergerNode, 0, 1);
//connect output #0 of the oscillator to input #1 of the mergerNode
currentTime = context.currentTime;
oscillatorR.start(currentTime);
oscillatorR.stop(currentTime + 2);

You create a silence node by creating an AudioBufferSourceNode, just like you would for any sample, and then not initializing the buffer property. The W3C spec guarantees that this produces a single channel of silence. (As of April 2014, this works in Chrome, but does not work in Firefox 28. In Firefox, the input is ignored and the result is the tone playing on both channels.)

Unused nodes get removed automatically

You might think that if you want to have two sounds playing in different channels – one sound in left, another in right – you don’t need to create dummy nodes. After all, the ChannelMergerNode will have two input channels.

In the code below, we want to play a 440 Hz tone in the left channel for 2 seconds, and a 2400 Hz tone in the right channel for 4 seconds. Both tones start at the same time.

oscillatorL = context.createOscillator();
oscillatorL.frequency.value = 440;
oscillatorR = context.createOscillator();
oscillatorR.frequency.value = 2400;
mergerNode = context.createChannelMerger(2); //create mergerNode with 2 inputs
mergerNode.connect(context.destination);

oscillatorL.connect(mergerNode, 0, 0);
//connect output #0 of the oscillator to input #0 of the mergerNode
oscillatorR.connect(mergerNode, 0, 1);
//connect output #0 of the oscillator to input #1 of the mergerNode
currentTime = context.currentTime;
oscillatorL.start(currentTime);
oscillatorL.stop(currentTime + 2); //stop "left" tone after 2 s
oscillatorR.start(currentTime);
oscillatorR.stop(currentTime + 4); //stop "right" tone after 4 s

This code works as expected for the first 2 seconds – each tone is audible only on one channel. But then the left tone stops playing, and the right tone starts playing on both channels. What’s going on?

  1. When oscillatorL stops playing, it gets disconnected from mergerNode and deleted. The browser is allowed to do this because – as you recall – an OscillatorNode or AudioBufferSourceNode can only be used once, so after we call oscillatorL.stop(), oscillatorL becomes unusable.
  2. The ChannelMergerNode notices that it is left with only one channel of input, and starts outputting a mono signal.

As you can see, the most stable solution, if you want to access individual audio channels, is to always have a dummy node (or several, if you’re dealing with 5.1 or 7.1 audio) connected to your ChannelMergerNode. What’s more, it’s probably best to make sure the dummy nodes remain referenceable for as long as you need them. If you assign them to local variables in a function, and that function returns, the browser may remove those nodes from the audio graph:

function playRight()
{
    var oscillatorR = context.createOscillator();
    oscillatorR.frequency.value = 440;
    var mergerNode = context.createChannelMerger(2);
    mergerNode.connect(context.destination);
    var silence = context.createBufferSource();
    silence.connect(mergerNode, 0, 0);
    oscillatorR.connect(mergerNode, 0, 1);
    currentTime = context.currentTime;
    oscillatorR.start(currentTime);
    oscillatorR.stop(currentTime + 2);    
}

playRight();

Consider what happens at the time playRight() finishes. oscillatorR won’t get removed because it’s playing (scheduled to stop in 2 seconds). But the silence node is not doing anything and when the function exits, it won’t be referenceable, so the browser might decide to get rid of it. This would of course switch the output of the ChannelMergerNode into mono mode.

It’s worth noting that the above code currently works in Chrome, but it might not in the future. The W3C spec gives browsers a lot of leeway when it comes to removing AudioNodes:

An implementation may choose any method to avoid unnecessary resource usage and unbounded memory growth of unused/finished nodes. (source)

In Firefox, You cannot modify an AudioBuffer after you’ve assigned it to AudioBufferSourceNode.buffer

The following code attempts to generate and play a 440 Hz tone over a single channel:

SAMPLE_RATE = 44100;
buffer = context.createBuffer(1, 44100*2, SAMPLE_RATE);
//create a mono 44.1 kHz buffer, 2 seconds length
bufferSource = context.createBufferSource();
bufferSource.buffer = buffer;

soundData = buffer.getChannelData(0);
for (var i = 0; i < soundData.length; i++)
  soundData[i] = Math.sin(2*Math.PI*i*440/SAMPLE_RATE);
bufferSource.connect(context.destination);
bufferSource.start(0);

It works in Chrome, but fails in Firefox (28) without any error message. Why? The moment you assign buffer to bufferSource.buffer, Firefox makes the buffer immutable. Further attempts to write to the buffer are ignored.

This behavior is not covered by the W3C spec (at least I couldn’t find any relevant passage), but here’s a Mozilla dev explaining it on StackOverflow.

Windows bug: AltGr key stops working after you open a “Save As” or “Open File” window

While working on the next release of my Windows app for typing foreign characters and phonetic symbols, I stumbled on a pretty serious bug that affects the use of multiple keyboard layouts on Windows Vista, Windows 7 and (to a lesser extent) Windows 8.

What the bug looks like to the end user

Suppose your default Windows keyboard layout is US English, but you also want to use other keyboard layouts occasionally – maybe you’re an American learning French or a Pole who lives in the US, but wants to write in Polish every now and then. The Language Bar in Windows allows you to set a separate layout for each window, so let’s say you fire up Microsoft Word and change your layout to Polish.

Quick note: The Polish keyboard layout, like most non-English keyboard layouts, makes use of the right-hand Alt key, also known as “AltGr”, which is short for Alternate Graving. For example, to type the letter ł (pronounced like English w), you press AltGr+L.

After typing for a while, you decide to save your document. You bring up the Save As dialog box, type up a filename, and press OK. When you start typing again, you notice that you can no longer type any AltGr characters.

What’s going on? The act of opening the default Windows “Save As” (or “Open File”) dialog disables the AltGr key. The AltGr characters are not accessible in the dialog (you cannot use them in file names). More seriously, once you close the dialog, AltGr will remain broken in your application, even though the Language Bar will report that you are using the correct layout. At first, I thought it was lying, but it’s not – technically, the layout is still in effect. It’s just that the AltGr key is no longer working; it becomes a regular Alt key.

The same happens if your default Windows layout uses AltGr and you set just one window to a non-AltGr layout such as US English. If you open the “Save As” or “Open File” dialog, the right Alt key will turn into AltGr. This means, for example, that hitting right-Alt+F will no longer bring up the File menu.

Which versions of Windows are affected?

I’ve reproduced this bug on Windows Vista, Windows 7, and Windows 8. Windows XP seems immune.

Note that the default setting in Windows 8 is to have a single keyboard layout for all applications. This bug will affect you only if you specifically go to the language settings and choose the option to enable per-app keyboard layouts.

The right way to stress-test an overclocked PC

Consider the following situation: You’ve overclocked your CPU, set the core voltage (Vcore) to some reasonable number, and then it’s time for some stress testing to make sure your rig is stable. You follow all the standard recommendations that you can find on overclocking forums: you run Prime95 for 12-24 hours, do a few hours of FurMark, and a few hours of IntelBurnTest for good measure. All the tests complete without a hitch. Congratulations! Your system is now considered stable.

But then you run Crysis or Battlefield 3 and you get random lockups and reboots. What’s going on?

The problem is that you stress-tested the CPU and GPU separately. That doesn’t guarantee that your system will be stable when both the CPU and the GPU are under load. Interestingly, loading the GPU can make your CPU unstable!

In other words, to be stable under combined CPU+GPU loads, your CPU may need a higher Vcore than it does for isolated CPU loads. That’s why the Vcore you arrived at using Prime95 or IBT may be too low to guarantee CPU stability when the GPU is under stress.

Here’s the story of how I realized it:

I had overclocked an i5 3570K to 4.3 GHz at 1.25 Vcore. The system had successfully completed the following stress tests:

  1. Prime95 Blend (all cores) for 14 hours
  2. Prime95 Small FFT (all cores) for 8.5 hours
  3. FurMark for 3 hours
  4. IntelBurnTest on Standard for 2 hours
  5. IntelBurnTest on High for 1 hour

Most overclockers would agree that these results look rock-solid. However, when I ran IntelBurnTest and FurMark simultaneously, I was shocked to see FurMark fail almost immediately. I repeated the experiment several times and the time to failure was always between 5 and 30 minutes. I started coming up with hypotheses:

Hypothesis #1: The PSU can’t supply enough power for the combined CPU+GPU load. The Corsair HX520W supplies 480 watts on the 12V line; an overclocked 3570K + HD7850 shouldn’t draw more than 300 W, but there’s also the motherboard, and the PSU is kind of old – who knows, maybe the capacitors have aged?

Refutation: After replacing the PSU with the Be Quiet! Straight Power E9 580 W (564 W on the 12 V line), the symptoms were exactly the same. It wasn’t a PSU problem!

Hypothesis #2: The increased heat production is causing the GPU, CPU, or video card VRMs to overheat.

Refutation: (1) GPU and CPU core temperatures were carefully monitored during stress testing and did not exceed 90°C. (2) During isolated CPU/GPU stress testing, CPU/GPU core temps were the same, yet there were no crashes. (3) With an open case and all fans set to maximum, the CPU+GPU test failed just as quickly. It was not a heat issue.

That left me with only one hypothesis.

Hypothesis #3: Loading the GPU is somehow causing the CPU to lose enough power to become unstable. In other words, the CPU Vcore is set high enough for isolated CPU load, but not high enough for combined CPU+GPU load. This was a novel hypothesis; I hadn’t seen it discussed in any of the overclocking resources that I had read.

Confirmation: In the words of Colonel Hans Landa, that’s a bingo! Upping the Vcore from 1.25 V to 1.275 V improved the stability by a large margin. Instead of failing after 5-30 minutes (as verified in multiple tests), IBT+FurMark failed after 108 minutes. (Notice that if the crashes had been due to overheating, the test would have failed more quickly than before, as increasing the CPU Vcore made the CPU hotter.)

Still, the system was not fully stable. In order to make it IBT+Furmark stable for several hours, I would have probably had to increase Vcore to around 1.3 V. Incidentally, this is close to the Vcore that the CPU chooses automatically for a 4.3 GHz clock speed, if you select the so-called “offset mode” instead of forcing a fixed Vcore. The lesson here would be that Intel knows what they’re doing when choosing these automatic settings.

The right way to ensure your overclock is fully stable

Run FurMark and IntelBurnTest at the same time for a few hours – at least as long as you expect to operate with combined CPU+GPU load. For example, if your typical gaming session is 3 hours, you should run IBT+FurMark for at least 3 hours. Of course more is better.

One tricky part to combined CPU+GPU stress testing is that FurMark needs some free CPU cycles in order to stress the GPU properly. If you fully load the CPU with IBT, Furmark will be bottlenecked and the GPU load will be much less than 100% – on my system it was around 75%.

The solution is to find the right settings for IntelBurnTest that will result in stressing the CPU while leaving just enough free CPU cycles to allow FurMark to get GPU load above 95%. In my case, the highest combined load was produced with IBT set to “High” and 3 threads.

Another piece of advice is to stick to “offset mode”, i.e. let the CPU set the Vcore automatically depending on the clock frequency. This may result in rather high voltages and high power draw (for example, a 3570K @ 4.3 GHz and full load has a Vcore of 1.32 V, which is higher than usually reported by overclockers at this clock speed), but at least you’re using a Vcore that has been blessed (and presumably extensively tested) by Intel.

My personal choice was to scale back my overclock to 4.1 GHz and choose offset mode. This translates to a Vcore of only 1.192 volts under load and, as far as I can tell, complete stability (IBT+Furmark 5 hours with no error) – though of course you can never be 100% sure…

FAQ

Isn’t it overkill to stress-test the CPU and GPU at the same time? That depends. If you’re absolutely sure you’re never going to reach full or near-full CPU+GPU load, then I guess you can stick to standard, isolated stress testing. However, bear in mind that there are games which can place a very high load on the CPU and the GPU at the same time.

Are you saying that most overclocked systems out there are not truly stable? It would seem so. Most overclockers determine a “stable” CPU Vcore based on isolated CPU testing with something like Prime95 or IntelBurnTest. My experience shows that you need a much higher Vcore to ensure stability under combined CPU+GPU load. I suspect most OC’d systems would fail the IBT+Furmark test outlined here rather quickly; they might also crash when running certain games. Of course, my findings would be more trustworthy if someone replicated them – please post your experiences in the comments!

Why would loading the GPU make the CPU unstable? I’m no hardware engineer, but here’s a wild guess: Loading the GPU drains some of the power away from the CPU (or causes small voltage dips from time to time). Therefore, when the GPU is loaded, the CPU will need a higher Vcore to remain stable.

What was your exact setup?

  • Motherboard: Asus P8Z77-V Pro
  • CPU: Intel i5 3570K
  • CPU cooling: Noctua NH-U12P SE2, 120mm Enermax T.B. Silence fan
  • Video card: AMD Radeon HD7850 (MSI Twin Frozr III, 2 GB)
  • GPU cooling: Accelero S1 Plus, 120mm Enermax T.B. Silence fan
  • 16 GB RAM (two 8 GB sticks, Kingston HyperX)
  • SSD: Crucial M4 256 GB, HDD: Western Digital Red 2 TB (WD20EFRX)
  • Case: Fractal Design Define R4
  • Case cooling: 1 rear 140mm Fractal Design Silent Series R2 fan
  • PSUs tested: Corsair HX520W / Be Quiet! Straight Power E9 580W

In search of a quiet PSU

Something’s amiss with the current crop of power supply units (PSUs) for desktop PCs. It seems all of them whine, squeal, buzz, or emit some other type of electrical noise.

As I researched the purchase of a PSU for my new PC, I was surprised to notice a large number of user complaints about “coil whine”, an umbrella term that encompasses various kinds of noise given off by vibrating transformer coils. Annoyed users described purchasing a PSU only to find that their new component emitted an awful sound – for example, it buzzed when the CPU was under load, or squealed when the system was in standby mode.

I want to make a few things clear up front:

  • We’re not talking about el cheapo PSUs – these people bought high-quality midrange or high-end models from the most reputable vendors like Seasonic or Corsair.
  • We’re not talking about some sort of faint sound that is only audible if you put your ear to the PSU. We’re talking about noise that is clearly audible over quiet fans and hard drives, in a quiet room, from 1-5 meters away.
  • It does not look like these users were simply unlucky to receive faulty units. Many users exchanged their units, but their symptoms did not go away (though sometimes they were alleviated somewhat). In fact, after hours spent reading through forum threads and customer reviews, I can’t recall a single case where the replacement unit was completely quiet.

After reading all those troubling reports, I approached the purchase of a PSU with some trepidation. It appeared there was a significant chance that my new PSU would be noisy.

I crossed my fingers and ordered my first PSU:

Be Quiet! Dark Power Pro 10 650W

Vendor page

The Be Quiet! Dark Power Pro 10 is the top-end model from a relatively new German vendor. Be Quiet!’s slogan is “It’s not absolutely silent until it’s absolutely silent”. Their PSUs are manufactured by FSP, a well-known PSU manufacturer based in Taiwan. The Be Quiet! Dark Power Pro 10 has earned the Editor’s Choice award from Silent PC Review, which is the best online resource dedicated to silent computing. SPCR’s review describes the Dark Power Pro as “extraordinarily quiet”. I was unable to find any user reports about electrical noise, though it has to be noted that Be Quiet’s PSUs are not the most popular choice and are unavailable in many markets.

The Dark Power Pro 10 looks solid and well-made, and the 135-mm fan was totally inaudible in my system (which probably consumes something like 300 watts under full load). However, the unit buzzed under light and medium loads — for example, while booting Windows, scrolling the browser window, or stress-testing only one CPU core. The buzz was (barely) audible from 2 meters away in a closed, well-dampened case (Fractal Define R4). I would compare the sound to that of a fly caught inside the PSU, or the seek noise of a hard drive. There was no buzzing under full load and in idle.

Putting the CPU (i5 3570K) on fixed voltage dulled the sound a bit, as did disabling the C1E power saving mode, but the improvement was small. I tried 20 or 30 other BIOS settings related to CPU power management, but these had no discernible effect on the noise.

Since I do not enjoy listening to an insect-like sound every time I scroll a webpage, I returned the unit and got another one:

Be Quiet! Straight Power E9 580W CM

Vendor page

This is Be Quiet’s midrange model, with very similar characteristics and a few missing gimmicks (such as less flashy packaging). I bought it because this review (in German) says it has absolutely no electrical noise.

Initially, it seemed that the Straight Power had very little buzzing — the loudest buzz I was able to generate was audible from 30-50 cm away (the Dark Power’s buzz was audible from 2 meters away). It wasn’t as silent as my old Corsair HX520W, but I was willing to live with a small amount of buzzing, especially that I keep my PC under a desk.

However, my evaluation changed when I plugged in my Dell monitor (2209WA), the PSU started buzzing quite loudly. It was a constant sound, independent of system load. I tried plugging in other devices (monitors, laptop PSU, etc.) to the same AC circuit, but only the Dell display makes it buzz. Which was a problem because the Dell is my main display!

Now, I don’t know if the buzzing is the “fault” of the PSU or the Dell display, and I don’t really care. All I know is, this symptom is not present in my old PSU, so the Straight Power had to go.

Seasonic X-560

Vendor page

I had mixed feelings about ordering a Seasonic PSU. On the one hand, Seasonic products are a long-time favorite of Silent PC Review; on the other, Seasonic-made PSUs are the ones which appear most often in reports of coil whine (though it could be a side effect of their popularity).

The Seasonic X-560 was, by a large margin, the loudest PSU I have tried so far. It was pretty quiet in idle and under medium load – apart from a bit of a high-pitched squeal that was only audible up close. Under high load (specifically, when stress-testing the GPU in FurMark), there was a clearly audible crackling sound (audible from about 1 meter away). But the Seasonic X-560 would show its true acoustic power only after I launched Mass Effect 3. As soon as the welcome screen loaded, it started giving off a constant, ridiculously loud hiss that sounded like releasing compressed air or perhaps running water. The noise was as surprising as it was loud – it was the loudest sound I had ever heard from a PSU, and it was easily audible from 5 meters away.

I also have to mention that the power connectors are poorly made. Plugging the ATX cable to the motherboard was quite an adventure – I nearly gave up, and at one moment I was afraid that I had damaged the socket! The plug only went in after I figured out a way to slide it in at a specific angle with the right amount of sideways pressure. Unplugging the cable was equally “exciting”. This does not appear to be an isolated case – here’s another user report (in Polish). The CPU power cable was also somewhat difficult to plug in. Poorly fitted cables are something that simply should not happen with a high-end, expensive product like a Seasonic X-Series PSU.

Right now, Seasonic still has a good reputation, but I can’t imagine it will last very long.

Enermax Triathlor 550W

Vendor page

(This is the version without modular cables, as opposed to the Enermax Triathlor 550W FC. The tech specs of both models are identical, though it’s possible that the FC has a different fan profile.)

After trying three “80 Plus Gold” PSUs, I decided to try an “80 Plus Bronze” model. The first thing that I noticed after installing the Enermax Triathlor 550W was how loud the fan was. While the PSU is fitted with the Enermax T.B. Silence 120mm fan, which is a high-quality fan capable of silent operation, the rotation speed is way too high. Judging by the noise level, the idle rotation speed is around 900 rpm. This produces an unpleasant whine and makes the PSU easily the loudest component in my PC.

To make things worse, the PSU ramps up the fan speed quite aggressively – around 40% load (220 W), the noise becomes much louder as the fan exceeds 1000 rpm. Such intense cooling appears unnecessary – when I put my palm next to the exhaust vent, I noticed that the air blowing out of the PSU wasn’t warm in the least bit. It’s as if the fan controller of the Triathlor 550W is trying to keep the PSU at room temperature at all times.

What about electrical noise? As you can imagine, testing for electrical noise in a unit with a loud fan isn’t exactly easy. However, my standard testing procedure revealed a buzz when running Mass Effect 3. The buzz is audible at a distance of 1-2 meters, even with the fan whooshing like crazy. There was also a softer buzz when running FurMark.

In short, even if the Enermax Triathlor didn’t have an outrageously loud fan, it could not be considered quiet due to the buzz.

Be Quiet! Pure Power L8 530W CM

Vendor page

My adventures with the above four PSUs revealed a surprising relationship: the more expensive and power-efficient a PSU was, the more electrical noise it had. An expensive and “reputable” Seasonic X-series was much worse than the less expensive BeQuiet! Dark Power, which in turn was worse than a middle-tier BeQuiet! Straight Power. On the other hand, my experience with the Enermax Triathlor showed that cheapness often means an unacceptably loud fan.

So, for my fifth PSU, I was looking for a relatively cheap unit with a quiet fan profile. I was thinking about Nexus PSUs, but I couldn’t find them in Poland, so I chose another BeQuiet! PSU: the Pure Power L8 530W CM. The Pure Power is quite cheap: about 40% cheaper than the Seasonic X-Series!

The first thing I noticed is that the fan on the Pure Power always starts at full speed, so when you turn on your computer, there is a loud whooshing sound that subsides after 2-3 seconds as the fan slows down to its normal operating speed. How loud is it at normal operating speed? Well, it seems slightly louder than the BeQuiet! Straight Power, BeQuiet! Dark Power or Corsair HX 520W, but the difference is subtle and, with the PSU mounted at the bottom of the case, I daresay immaterial. At a distance of over 1 meters, the noise simply blended in with that of other components (very quiet 120-mm fans and super-quiet WD Red hard drive). The noise quality was quite broadband, there were no traces of whine, as is the case with some fans.

The fan profile is very quiet — I couldn’t get the fan to speed up even after fully loading my i5-3570K CPU (@ 4.1 GHz) and my Radeon HD7850 at the same time, which probably resulted in a power draw exceeding 250 W on the 12V line, which is more than 50% of the maximum output of the PSU on that line. The Be Quiet! stayed quiet no matter what I did.

There was a clicking sound coming from the fan (which I verified by using the SPCR technique of forcibly stopping it with a plastic straw). The sound was inaudible at a distance of over 1 meters; however, there is a risk it could get worse with time. Unfortunately, the fan on the Pure Power is a sleeve-bearing fan which is not ideal for horizontal operation.

Now for the most important part: electrical noise. Unlike its more expensive brothers, the BeQuiet! Pure Power 530W exhibited virtually no electrical noise (whining, buzzing, clicking etc.) under normal usage or artificial load. The Dark Power buzzed when scrolling web pages and during other light tasks, the Straight Power buzzed when I plugged in my Dell monitor — here, there is no noise (unless you put your ear to the PSU). There was likewise no electrical noise when stress testing under Prime95, IntelBurnTest, FurMark or IntelBurnTest+FurMark. I could get the PSU to emit a slight buzz when playing Mass Effect 3 (which is, for some reason, the noisiest application I could find). However, I could not hear the buzz from more than 1 meter away when the PSU was in a closed case.

To sum up, the BeQuiet! Pure Power 530W CM is certainly the quietest PSU I have tested — and the only one which could be described as completely inaudible in typical usage (closed case under a desk). If you believe a PSU should be neither seen or heard, you should definitely check out the BeQuiet! Pure Power 530W CM.

Is the Pure Power as good as my trusty old Corsair HX520W? No, it has a tiny bit of buzzing and the fan is probably a tiny bit louder. But of the PSUs you can buy today, it’s one of the quietest, if not the quietest.

FAQ

How do you know the noise was made by the PSUs, and not your motherboard, video card, etc.? I put my ear to the PSU, the motherboard and the video card. There’s no doubt that the PSUs were the source.

What’s your setup?

  • Motherboard: Asus P8Z77-V Pro
  • CPU: Intel i5 3570K (overclocked to 4.1 GHz)
  • Video card: AMD Radeon HD7850 (MSI R7850 Twin Frozr III, 2 GB)
  • 1 SSD drive and 1 very quiet mechanical hard drive (WD Red 2 TB)
  • Case: Fractal Design Define R4
  • Case fan: 140 mm at 500-600 rpm
  • CPU fan: 120 mm at 600-700 rpm
  • GPU fan: 120 mm at 600-700 rpm

Why do you think current PSUs are prone to electrical noise? I have a hunch that it has something to do with rising efficiency. (This thread quotes others who feel the same way.) A few years ago, when nobody worried about PSU efficiency, you’d have to be very unlucky to get a buzzing or whining PSU. But today, manufacturers are scrambling to squeeze every ounce of efficiency from their designs. They have persuaded consumers (with the aid of reviewers) that it really matters whether their next PSU is an “80 Plus Bronze” or an “80 Plus Gold” (in reality, of course, nobody will notice a difference in their electric bill). As in all situations where everybody is fixated on a single parameter — whether it’s GPAs in schools, display contrast ratios or camera megapixel counts – the one parameter goes up while the overall quality suffers. In this case, silence is sacrificed in order to gain the prestige associated with an “80 Plus Gold” or “80 Plus Platinum” badge.

Online Tone Generator

screenshot

I made an online tone generator based on the Firefox Audio API HTML5 Web Audio API. It’s basically a large logarithmic slider that allows real-time, smooth frequency changes. You can also fine-tune the frequency in 1 Hz increments, if necessary.

There are other tone generators on the Web, but they are not as cool (if I do say so myself) and/or they require Java or Flash.

Warning: my generator only works on recent browsers which support the Web Audio API, such as Chrome and Firefox.

What can you use a tone generator for? You can do a science experiment with resonance, tune a musical instrument, test your new audio system (how low does it go?), test the limits of your hearing (I can hear absolutely nothing above 19,000 Hz, even at maximum volume), or figure out your tinnitus frequency to better target therapy.

Plasticity – train your ears

image

Plasticity is a pitch discrimination game — that is, a game which tests and improves your ability to distinguish between similar sounds based on their frequency (pitch). You hear two sounds, which may have the same or different frequency (with 50-50 probability) and your job is to say whether they have the same frequency or different frequencies. At first, the differences are fairly obvious, but as you level up, they become smaller and smaller, which makes your job harder.

Plasticity can be a fun game to play (at least, if you believe some of my friends). In addition, it might be helpful if you want to improve your pitch discrimination skills – for example, if you’re a musician.

Plasticity is based on the Firefox Audio API and, as such, requires Firefox 4 or higher. Plasticity uses the HTML5 Web Audio API. It has been tested to work (at least) in recent versions of Chrome and Firefox.

I wrote Plasticity to treat my tinnitus (a phantom sound in my head). The idea was to re-wire the auditory cortex in my brain through repeated training in order to change my perception of the tinnitus sound. The name “Plasticity” refers to cortical plasticity – the ability of the cortex to reorganize in response to stimuli. Did Plasticity help my tinnitus? Well, I no longer have a tinnitus problem, though I am not sure to what extent Plasticity contributed to the improvement. If you have tinnitus (especially pure-tone tinnitus), you might as well give it a try. Here are some tips on how to use Plasticity for tinnitus.

Feedback request

If you’re using Plasticity for your tinnitus, don’t forget to post a comment below. I want to know how it went!