Re: [haskell-art] Haskell audio I/O packages
hi john, John Lato wrote: Using unsafeFreezeIOCArray and my stream implementation provides the fastest version yet, with an average of about 1.9s per run. This is in the hsndfile.hs test code as function test1. For the record, the stream implementation and fold I'm using are copied from Data.ByteString.Lazy. I changed the types to suit this code, but that's the source. thanks for posting the code. i'm not very convinced of lazy IO, but i'd be very interested in incorporating an iteratee based approach into hsndfile. i'm currently finalizing various api changes and extensions (mostly to do with abstracting both mutable and immutable buffers) and when i'm done i'll have a look at what you did in hsoundfile-3. obviously oleg's iteratee code is not hackaged yet, and i couldn't find it anywhere else, do you have any pointers? thanks, sk ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell audio I/O packages
On Tue, 9 Dec 2008, stefan kersten wrote: thanks for posting the code. i'm not very convinced of lazy IO, but i'd be very interested in incorporating an iteratee based approach into hsndfile. What are the reasons, you do not like lazy IO? Yes, currently it's a hack using unsafeInterleaveIO. But I hope someday one can hide this safely in a nice monad. But in general I find lazy stream processing a very elegant way of programming. Why else should we use Haskell and not, say OCaml? ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell audio I/O packages
On Tue, Dec 9, 2008 at 4:45 PM, stefan kersten [EMAIL PROTECTED] wrote: hi john, John Lato wrote: Using unsafeFreezeIOCArray and my stream implementation provides the fastest version yet, with an average of about 1.9s per run. This is in the hsndfile.hs test code as function test1. For the record, the stream implementation and fold I'm using are copied from Data.ByteString.Lazy. I changed the types to suit this code, but that's the source. thanks for posting the code. i'm not very convinced of lazy IO, but i'd be very interested in incorporating an iteratee based approach into hsndfile. i'm currently finalizing various api changes and extensions (mostly to do with abstracting both mutable and immutable buffers) and when i'm done i'll have a look at what you did in hsoundfile-3. obviously oleg's iteratee code is not hackaged yet, and i couldn't find it anywhere else, do you have any pointers? thanks, sk Hi Stefan, It's available at http://okmij.org/ftp/Haskell/Iteratee/ His DEFUN slides and notes, found at http://okmij.org/ftp/Streams.html#iteratee, are also helpful. I think it's pretty obvious how to apply this to hsndfile. However, I just noticed that Oleg has posted a TIFF library using an Iteratee approach. It supports seeking/random access and various other things that directly apply to the matter at hand. Looks like I'll have to do some studying again... http://okmij.org/ftp/Streams.html#random-bin-IO ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell audio I/O packages
On Fri, Dec 5, 2008 at 7:04 PM, stefan kersten [EMAIL PROTECTED] wrote: Henning Thielemann wrote: Thank you for this benchmark! I'm particularly interested in StorableVector because I hacked it quite a bit and use it for my own signal processing. I would also like to know how Fusion+Inlining improves the picture, but I do not know if there is anything to fuse at all in this simple example. Can you show us the actual test you run? I would then compare with my fusing signal data type from the synthesizer package. yes, thanks john, very interesting ... i'd also be interested in the benchmarking code ;) I'll try to post the code tonight after work. I'll also post the library versions I tested, which in all cases were the latest available on Hackage at the time I ran my tests. One thing to keep in mind is that, in general, the benchmarking code is pretty simple. I was trying to approach this from the point of view of an average user (e.g. me), who may not be familiar with all the Haskell optimization strategies. I doubt there's anything to fuse in this example, but I don't know much about fusion implementations. I have tried inlining certain functions, but either there was no change (which was my expectation), or a slight slowdown. hsndfile - a recursive I/O function reads a chunk from the file (using IOCArray type) and accumulates the maximum values from each chunk. I attempted to create a framework like used for HSoundFile-3, however performance dropped dramatically; I suspect the slowdown is mostly from the process of freezing mutable arrays to immutable arrays. for CArray i've been using unsafeFreezeIOCArray, which does an O(1) conversion (simply keeping the pointer to the mutable array). Thanks, I'll try that. For chunked data types, all data is with chunk size 1000. All timing/memory data is the median value from multiple runs. In general different runs had very similar performance. Timing results: HSoundFile-3, StorableVector - real 16.5s HSoundFile-3, UArr- real 15.7s HSoundFile-3, List - real 17.6s Is this the plain Prelude [] type? Why are List and StorableVector similar in speed? Yes, it's the plain Prelude [] type. I expect they're similar in speed because of the particular implementation of AudioBuffer in HSoundFile-3. Specifically, the AudioBuffer class has a fromList function which is used to create the buffer from a Data.Binary decode operation. The UArr API is somewhat optimized for this use case, however I believe it's relatively inefficient for StorableVector. If someone more familiar with StorableVector were to write the AudioBuffer instance, I think it would perform better. Adding specialized instances for AudioBuffer UArr and AudioBuffer StorableVector would likely produce a significant gain; about 10% for UArr and probably less for StorableVector. Changing the AudioBuffer class to avoid the intermediate List is trickier. Last time I tried, I don't believe I found a successful approach. Given my results, my next approach will be an Enumerator API that uses hsndfile to actually read from the file. I think that would have nearly all the performance of hsndfile with a functional, composable interface. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell audio I/O packages
On Mon, 8 Dec 2008, John Lato wrote: On Fri, Dec 5, 2008 at 4:36 PM, Henning Thielemann [EMAIL PROTECTED] wrote: Data Types: HSoundFile-3 - custom AudioBuffer class. Implementations are provided for UArr Double, List Double, and StorableVector Double StorableVector or StorableVector.Lazy? The latter seems appropriate here. I think that StorableVector is the correct choice. AudioBuffers are meant to be read/written strictly, in small chunks. I could certainly try StorableVector.Lazy. It may in fact be more performance. StorableVector.Lazy uses chunks. It won't be faster but will require less memory for stream operations. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell audio I/O packages
Henning Thielemann wrote: Thank you for this benchmark! I'm particularly interested in StorableVector because I hacked it quite a bit and use it for my own signal processing. I would also like to know how Fusion+Inlining improves the picture, but I do not know if there is anything to fuse at all in this simple example. Can you show us the actual test you run? I would then compare with my fusing signal data type from the synthesizer package. yes, thanks john, very interesting ... i'd also be interested in the benchmarking code ;) hsndfile - a recursive I/O function reads a chunk from the file (using IOCArray type) and accumulates the maximum values from each chunk. I attempted to create a framework like used for HSoundFile-3, however performance dropped dramatically; I suspect the slowdown is mostly from the process of freezing mutable arrays to immutable arrays. for CArray i've been using unsafeFreezeIOCArray, which does an O(1) conversion (simply keeping the pointer to the mutable array). For chunked data types, all data is with chunk size 1000. All timing/memory data is the median value from multiple runs. In general different runs had very similar performance. Timing results: HSoundFile-3, StorableVector - real 16.5s HSoundFile-3, UArr- real 15.7s HSoundFile-3, List - real 17.6s Is this the plain Prelude [] type? Why are List and StorableVector similar in speed? i'm curious about that one too ... sk ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
