Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
AlexKnauth opened this issue Aug 4, 2017 · 0 comments
Open

Comments

@AlexKnauth
Copy link

AlexKnauth commented Aug 4, 2017

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant