[Haskell-cafe] Precise timing

[Heinrich Apfelmus]

Jeffrey Brown wrote:
> Thanks, everybody! Those were incredibly informative answers. This list is
> amazing.
> 
> Heinrich's suggestion of compiling with "-threaded" was by itself
> sufficient to get the first rhythm to sound right.
> 
> The second rhythm, however, still blurs into a string of beeps of the same
> duration even after I throw all of Heinrich's and Carter's suggestions at
> it by doing this:
> 
> ghc --make fast -threaded -fno-omit-yields -with-rtsopts -C0
> 
> (although I should admit to not really knowing what I'm doing when I run
> that) where fast.hs is this:
> 
> import Control.Concurrent
> import Text.Printf
> import Control.Monad
> import System.IO
>  main = do
> hSetBuffering stdout NoBuffering
> mapM_ note (cycle [1,1,2])
>  beat = round (10^6 / 10) -- measured in microseconds
>  note :: Int -> IO ()
> note n = do
> threadDelay $ beat * n
> printf "\BEL\n"
> 
> I therefore suspect I have to teach myself, as Brandon suggested, a
> realtime scheduler. This seems like a general, powerful thing:
> http://hackage.haskell.org/package/atom

I would be hesitant to attribute your problem to the scheduler. An 
alternative explanation could be the following: The sound file played by 
the terminal when it encounters the \BEL character is longer than 100ms. 
A new sound will be played only when the previous sound has finished 
playing, so the terminal will queue \BEL characters until the previous 
ones have finished. But since they arrive too fast, there will never 
have any pause in between and you hear a constant rhythm.

I can't test this theory because the \BEL character doesn't work in my 
Terminal application, but I have just listened to a kick drum sample on 
autorepeat and got a tempo of less than 200bpm. This means that the file 
is significantly longer than 100ms (or that starting the file from the 
beginning again takes a long time, but I did not notice any extended 
silence). An length of 100ms would correspond to 600bpm.

To test this theory, you can try to sweep through lower tempi like 
200bpm-500bpm and look for the threshold when the actual tempo plateaus 
even though you are increasing the scheduling tempo. This should be 
correspond to the length of the audio file.

Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com