[Haskell-cafe] Precise timing

John Lato jwlato at gmail.com
Mon Oct 20 00:29:48 UTC 2014


I was going to suggest something like this.  The usual approach in audio
software is to have a main processing loop that never yields (or calls
threadDelay, or blocking operations).  This loop runs at a fixed rate, and
is responsible for handling the scheduling, mixing, writing to output,
etc.  You can have other threads that work on other processes, but if
they're time-sensitive again you wouldn't want them to be de-scheduled,
unless you can reschedule them in advance then wait.

Currently it's hard to do this very reliably in Haskell because the RTS has
no support for thread priorities or anything like that.  Even if you use
posix-realtime, you'd still need to be aware that the Haskell RTS can
unschedule threads, or move calculations around.  And a stop-the-world GC
could theoretically happen at any time.

That said, I've had decent success doing real-time work so long as the CPUs
don't get completely saturated.

An alternate approach is to hand off the real audio processing to something
like csound or OSC.  At least with csound I know it's possible to pipe raw
audio data via the API, and I imagine OSC has a facility for this as well.

John L

On Mon, Oct 20, 2014 at 5:22 AM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> I think threadDelay is the wrong operation here. Its fundamentally a
> primitive for **spreading out** compute, rather than *scheduling compute*.
> one (crazy) idea might be the following, say you wanna do an event every X
> milli seconds (with some error tolerance about the precise timing),
> do a threadDelay for  1/2-2/3rds X, then poll the time constantly :)
>
> OTOH, as other folks are suggesting, theres probably fundamentally better
> primitives already available.
>
> On Sun, Oct 19, 2014 at 5:11 PM, Brandon Allbery <allbery.b at gmail.com>
> wrote:
>
>> On Sun, Oct 19, 2014 at 3:44 PM, Jeffrey Brown <jeffbrown.the at gmail.com>
>> wrote:
>>
>>> You mean I should call chrt from the command line after starting the
>>> process, to modify its priority?
>>>
>>
>> Normally you'd use it to run the program. But, as I said at least twice,
>> it's Linux specific.
>>
>>
>>> This documentation
>>> <http://hackage.haskell.org/package/posix-realtime-0.0.0.1/src/System/Posix/Realtime/RTSched.hsc> for
>>> the posix-realtime package
>>> <https://hackage.haskell.org/package/posix-realtime> says that it has a
>>> sched_setscheduler function. That supposedly exists on my OS (OS X 10.9).
>>> The chrt command, on the other hand,
>>>
>>
>> Does it warn you that you need privileges (probably root) to switch to a
>> higher scheduler level? Normally realtime and other high priority
>> schedulers require elevated privileges, whereas lower priority schedulers
>> such as SCHED_IDLE don't.
>>
>> I should note that I see no manpage for sched_setscheduler on 10.9.5, nor
>> do I find it in any of the dylibs in /usr/lib.
>>
>> --
>> brandon s allbery kf8nh                               sine nomine
>> associates
>> allbery.b at gmail.com
>> ballbery at sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad
>> http://sinenomine.net
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20141020/80825d23/attachment.html>


More information about the Haskell-Cafe mailing list