I'm amazed that the almighty Google doesn't have a ready answer to the question "what is VCHIQ?" I'm a longtime kernel geek and not a Broadcom employee, nor am I BCM283* expert, but here's what I've found for (maybe) posterity:
From the Raspberry Pi kernel branch:
Kernel to VideoCore communication interface for the BCM2708 family of products.
What's worth noting here is that the VideoCore is (surprise surprise) the video controller for the SoC that the Pi runs, and it would appear that this is a handy way to run more-or-less direct IOCTLs to various subsystems hooked into the GPU. That this includes video is no big surprise, but I guess it makes sense that the camera interface has its silicon within VideoCore given all the codec stuff video needs to do.
So why is audio control run through the VideoCore as well (otherwise it wouldn't need VCHIQ to control it)? I suspect that, given the fact that VC has hardware support for H.264 and other codecs (and because you can route audio through HDMI), it was just the easiest place to put the silicon. Well, that and the fact that the BCM chip has two MMUs (one for the VC+ARM, another for normal OS use--see diagram on pg 5), which makes zero-copy DMA possible (no need to copy things to the audio silicon--just tell it that a chunk of memory belongs to it and not the CPU. Dunno yet if they actually do this under the covers, but why wouldn't you?).
Note that the IOCTLs on VCHIQ don't really transfer data per se--they set up DMA and other operations between memory chunks and send commands to various bits. This can be super dangerous, as you could potentially screw with internal kernel data structures from userspace, crash the GPU, sling around corrupt data, etc. So don't set /dev/vchiq to mode 777!!!
In any case, the short answer to "what is VCHIQ?" Here it is:
VCHIQ is a command interface between the running Linux kernel and peripherals (among other things) in the VideoCore silicon. /dev/vchiq provides generic userspace access to those commands for use by (at minimum) the camera and audio subsystems as well. It's a decently dangerous interface to expose to random programs, hence the somewhat restrictive permissions by default.
There are people that are up to their eyeballs in the BCM hardware in the RPi community; I'm not one of them (I'm perhaps ankle-deep after a couple of hours of research :-) ). That said, I think this is a decent high-level overview and would welcome additions/corrections.
As far as why www-data requires permission, that would be because your CGI program is spawning child processes as that user. I don't know that particular player well, but better practice would usually be to run some specialty daemon to control the program that's interfacing to sound and controlling it from CGI using a UNIX socket or similar interface rather than directly spawning a child.
Indeed, a security vendor got busted a while back for allowing their web server root access to their machine. They probably did this to ease process management rather than writing this type of middle layer, but it's a security no-no. Giving apache basically unfettered access to GPU DMA is an equally bad idea (though much harder to exploit I admit).
Hopefully this answers your question.
