RSound function breaks its own contract using stream-play/unsafe

This might be a problem with either RSound or Portaudio. The contract on RSound's signal/block-play/unsafe promises that it will treat its first argument, block-filler, as a (-> cpointer? natural? void?) function, but it passes it to Portaudio's stream-play/unsafe, which treats it as a (-> cpointer? int? void?) function.

So, stream-play/unsafe calls it with the int -630867962 where signal/block-play/unsafe promised a natural number.

Is stream-play/unsafe in the wrong here? Is this some kind of overflow, or is it supposed to be able to use negative integers?

.../collects/racket/contract/private/blame.rkt:163:0: signal/block-play/unsafe: broke its own contract
  promised: natural?
  produced: -630867962
  in: the 2nd argument of
      the 1st argument of
      (->
       (-> cpointer? natural? void?)
       nonnegative-real?
       (or/c nonnegative-real? false?)
       (-> nonnegative-real?))
  contract from: 
      <pkgs>/rsound/rsound/rsound-commander.rkt
  blaming: <pkgs>/rsound/rsound/rsound-commander.rkt
   (assuming the contract is correct)
  at: <pkgs>/rsound/rsound/rsound-commander.rkt:46.3

jbclements / portaudio

RSound function breaks its own contract using stream-play/unsafe #3