The first high-level interface involves copying the entire sound into a malloc’ed buffer, and then playing it. This is relatively low-latency. On the other hand, copying the sound involves doubling the memory required for the sound itself, so it’s a bad idea to call this for sounds that are really big (> 100MB?).
This function signals an error if start and end frames are not ordered and legal.
Here’s an example of a short program that plays a sine wave at 426 Hz for 2 seconds:
#lang racket (require (planet clements/portaudio) ffi/vector) (define pitch 426) (define sample-rate 44100.0) (define tpisr (* 2 pi (/ 1.0 sample-rate))) (define (real->s16 x) (inexact->exact (round (* 32767 x)))) (define vec (make-s16vector (* 88200 2))) (for ([t (in-range 88200)]) (define sample (real->s16 (* 0.2 (sin (* tpisr t pitch))))) (s16vector-set! vec (* 2 t) sample) (s16vector-set! vec (add1 (* 2 t)) sample)) (s16vec-play vec 0 88200 sample-rate)
The function returns a list contaning two functions: one that queries the stream for a time in seconds, and the other that stops the stream.
This function is believed safe; it should not be possible to crash DrRacket by using this function badly (unless you exhaust memory by choosing an enormous buffer size).
Here’s an example of a program that uses stream-play to play a constant pitch of 426 Hz forever:
#lang racket (require (planet clements/portaudio)) (define (buffer-filler setter frames base-frames) (define pitch 426) (for ([i (in-range frames)] [f (in-range base-frames (+ base-frames frames))]) (define sample (real->s16 (* 0.2 (sin (* tpisr f pitch))))) (setter (* i 2) sample) (setter (+ 1 (* i 2)) sample))) (define sample-rate 44100.0) (define tpisr (* 2 pi (/ 1.0 sample-rate))) (define (real->s16 x) (inexact->exact (round (* 32767 x)))) (match-define (list timer stopper) (stream-play buffer-filler 0.1 44100.0))
Note that this example uses a long buffer of 0.1 seconds (= 100 milliseconds) so that most GC pauses won’t interrupt it.
However, this a latency of 100ms is be pretty terrible for an interactive system. I usually use 50ms, and just put up with the occasional miss in return for lower latency.
The difference is that this function’s callback is called with a cpointer, rather than a set!-proxy. This saves the overhead of a function call and several checks, but perhaps more importantly allows the use of functions like memcpy and vector-add that can operate at much higher speeds (currently ~5x) than the current vector operations.