Send Beginners mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: Processing data from microphone interactively (Martin Vlk)
2. Controlling the ordering in the TOC of haddock html (martin)
3. Re: Difference of time execution times when measuring with
time and profiling (Javier de Vega Ruiz)
----------------------------------------------------------------------
Message: 1
Date: Sun, 25 Oct 2015 19:52:28 +0000
From: Martin Vlk <[email protected]>
To: [email protected]
Subject: Re: [Haskell-beginners] Processing data from microphone
interactively
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Heinrich,
this is a great and very useful response, thanks!
I am working through my implementation details and I'll post the result
when I have it.
Martin
Heinrich Apfelmus:
> Hello Martin,
>
> in digital signal processing (DSP), audio samples are traditionally
> processed in *blocks*. Typical blocks sizes for real-time processing are
> 64, 128 or 256 bytes.
>
> The reason for this is that audio processing is a performance-sensitive
> task. If your code is too slow, then it cannot process all audio in time
> and there will be jitter. Typically, the operations that are applied to
> a single block are fairly limited (mixing, convolution, ...) and can be
> optimized into a tight loop, which you can then reuse as a "black box".
> In contrast, operations that act on blocks (envelopes, ...) are more
> open-ended and you would have to pay attention to optimizing them each
> and every time you write a program.
>
> This is related to the concepts of "audio rate" and "control rate". The
> former is the frequency at which audio is sampled, i.e. the frequency
> "within" a block, while the latter corresponds to more coarse-grained
> operations, that are approximately the same on every block.
>
>
> For you, this means that you probably want to call the `simpleRead`
> function with a block size of 128 and process each block individually
> before requesting the next. If individual processing proves too slow,
> you will have to use data structures that are closer to the machine, and
> call the `simpleReadRaw` function instead.
>
>
> Best regards,
> Heinrich Apfelmus
>
> --
> http://apfelmus.nfshost.com
>
>
> Martin Vlk wrote:
>> Hi,
>> I am looking at reading sound from a microphone and controlling some
>> other activity based on the sound data as they come. The motivation for
>> this is writing some interactive animated graphics controlled by
>> properties of the sound from mic.
>>
>> I am using the pulseaudio-simple library to read sound from the computer
>> mic and that works fine. However the library function basically returns
>> sound samples as a list of predefined length and this is not well suited
>> for the kind of real-time processing I need.
>>
>> I am looking for advice on what would be a good idiomatic way to design
>> such a program in Haskell.
>>
>> From some research I am imagining I need something like the conduit
>> library to connect the sound data to other parts of my program, but I am
>> not sure how that would work or if it is a good idea in the first place.
>>
>> Or should I use some of the FRP libraries for this purpose?
>> Or some other approach?
>>
>> I'd appreciate some advice on the direction to take.
>>
>> Many Thanks
>> Martin
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
>
------------------------------
Message: 2
Date: Sun, 25 Oct 2015 21:00:14 +0100
From: martin <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: [Haskell-beginners] Controlling the ordering in the TOC of
haddock html
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hello all,
I just started using haddock and on the "Contents" page it list all my modules
and directories strictly in alphabetic
order. I get something like this
Modules
Domain
Domain.Item is about Items and their Positions
Domain.Location
Domain.Port
Domain.Process implements a general Process entity
Domain.System captures the state of the world
Event implements the possible Events
Misc
Misc.Lens provides poor-man's Lens support
Misc.Time implements Instant and Interval
Simulation is the main simulation engine
I'd rather see
Modules
Simulation is the main simulation engine
Event implements the possible Events
Domain
Domain.Item is about Items and their Positions
Domain.Location
Domain.Port
Domain.Process implements a general Process entity
Domain.System captures the state of the world
Misc
Misc.Lens provides poor-man's Lens support
Misc.Time implements Instant and Interval
Is there a way I can control the order in the TOC page?
------------------------------
Message: 3
Date: Mon, 26 Oct 2015 12:02:40 +0000
From: Javier de Vega Ruiz <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] Difference of time execution times
when measuring with time and profiling
Message-ID:
<CAB9urNTYoXRCFM=83Dy+mcFdDo5SNHdX-g7nerscqd=xsbo...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks Thomas,
I tried in Linux and the behavior of the time tool seems more reasonable
now:
real 0m46.743s
user 0m45.888s
sys 0m0.160s
After checking some of the RTS documentation, it turns out the GC's cost
centre is not included by default, in order to include I had to change the
-p to -pa which results in:
fast-fib +RTS -pa -RTS
total time = 47.43 secs (47433 ticks @ 1000 us, 1 processor)
total alloc = 44,128,957,088 bytes (excludes profiling overheads)
COST CENTRE MODULE %time %alloc ticks bytes
GC GC 86.0 0.0 40778 0
fastFibs.nextFib Main 13.1 99.6 6228 43952857104
This clearly states where that 86% difference was coming from, the GC,
which means the world makes sense again :)
Does someone know how to add the cost centre for GC without having to use
-pa?
Best regards,
Javier de Vega Ruiz.
On Fri, Oct 23, 2015 at 1:27 AM, Thomas Koster <[email protected]> wrote:
> Javier,
>
> On 23 October 2015 at 03:00, Javier de Vega Ruiz
> <[email protected]> wrote:
> > I am messing around with bang patterns and noticed some huge differences
> > between the total time as reported by the time tool and the .prof file.
> > Below is the code used.
> > Without bang patterns:
> > module Main where
> >
> > import Data.List
> >
> > fastFibs =
> > unfoldr nextFib (1, 1)
> > where nextFib (x, y) = Just $ (x, (y, (x + y)))
> >
> > main =
> > putStrLn $ (show n) ++ "th fib is: " ++ (show $ fastFibs !! (n - 1))
> > where n = 1000000
> >
> > With bang patterns:
> > {-# LANGUAGE BangPatterns #-}
> >
> > module Main where
> >
> > import Data.List
> >
> > fastFibs =
> > unfoldr nextFib (1, 1)
> > where nextFib (!x, !y) = Just $ (x, (y, (x + y)))
> >
> > main =
> > putStrLn $ (show n) ++ "th fib is: " ++ (show $ fastFibs !! (n - 1))
> > where n = 1000000
> >
> > when looking at the first through time and prof I get the following.
> > Without:
> > real 0m53.501s
> > user 0m0.015s
> > sys 0m0.328s
> > Thu Oct 22 16:46 2015 Time and Allocation Profiling Report
> (Final)
> >
> > fast-fib.exe +RTS -p -RTS
> >
> > total time = 9.52 secs (9520 ticks @ 1000 us, 1
> processor)
> > total alloc = 43,500,223,152 bytes (excludes profiling
> overheads)
> >
> > Please note the huge difference 53 vs 9 seconds.
> >
> > With:
> > real 0m10.095s
> > user 0m0.031s
> > sys 0m0.344s
> > Thu Oct 22 16:50 2015 Time and Allocation Profiling Report
> (Final)
> >
> > fast-fib.exe +RTS -p -RTS
> >
> > total time = 8.97 secs (8971 ticks @ 1000 us, 1
> processor)
> > total alloc = 43,500,309,960 bytes (excludes profiling
> overheads)
> >
> > Here differences seem to be much smaller.
> >
> > I am using Windows 8.1 64 bit, GHC 7.8.3 and measuring with the following
> > line:
> > ghc Main.hs -o fast-fib.exe -O2 -prof && time ./fast-fib.exe +RTS -p &&
> cat
> > fast-fib.prof
> >
> > Could someone please explain where the big difference is coming from and
> how
> > to change the measuring approach to get more consistent results?
>
> Before going into why the numbers are what they are, I think there is
> something wrong with your time tool on Windows. Your "user" time is
> suspiciously low in both measurements. When I ran your program on
> Linux, the report from the -s RTS option and the "real" and "user"
> numbers from the time tool were within milliseconds of each other
> (qualification: I used GHC 7.10.2).
>
> Apart from that, I am pretty sure the -p RTS option and the time tool
> are not measuring the same thing. I think the profiler samples "ticks"
> in the runtime, whereas the time tool and the -s option probably use
> CPU performance counters. Somebody more familiar with the GHC runtime
> should be able to give you more detail.
>
> --
> Thomas Koster
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20151026/aa78fd3b/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 88, Issue 24
*****************************************
