kernel - Hack pcm audio for firefox issue

kernel - Hack pcm audio for firefox issue

* Observed that the firefox thread handling sound output winds up being
  in a cpu-bound loop calling poll() on two descriptors, one being the
  /dev/dsp descriptor.  With some debugging, determined that this call
  occurs with the sound buffer ~slightly less than half full.

  The sound is generated via the dports/audio/alsa-plugins (oss) library,
  but the poll() appears to come from the snd_pcm_ioplug subsystem.  It
  appears that this subsystem has a bug in it when pacing sound output,
  it still polls and live-loops on the sound output descriptor even when
  it has no new data to send to the decriptor.

* There could be something else going on here with assumptions made by
  linux sound client code vs our implementation, but I don't know what
  they might be.

* This is probably not the correct fix, but we hack in a change to not
  generate POLLWR events until the sound buffer is at least half empty.
  This matches up with observed behavior from the above subsystem and
  prevents the cpu loop.

  It should be harmless to other code using kqueue/select/poll.

  Appears to fix firefox's live looping in poll() during sound and
  video (w/sound) playback.