* It still results in gaps (???).
   Under FreeBSD, even the expression `InputStream():play()` produces noise.
   Apparently, there is some kind of data corruption.
 * it's probably necessary to increase the input buffer size
   and tell Jackd about the difference (output - input buffer size) as
   an additional latency.

* This allows the native syntax `for f in Stream:iter() do ... end` without using lambda
  functions.
  Also you can use `break` and `return` statements.
* On the other hand we cannot exploit the extended xpcall() semantics and had to introduce
  another lambda in Stream:play().
* In general the number of function calls per tick stays the same.
  Stream:gtick() itself could be used as an iterator, but Stream:iter() adds checking for CTRL+C,
  resetting of the sample cache and binding functions.

* Especially useful to generate PDF plots for my thesis.

* The old implementation was simple but severely limited:
  * the resample factor (playback speed) could only be scalar
  * for infinite source streams, the algorithm would require infinitely growing memory.
    The algorithm therefore also wasn't realtime-safe and quite slow (probably because of reallocations).
* This could be made to work with stream-factors if the source stream is infinite,
  but we couldn't get rid of the memory requirements due to being based on IndexStream.
* Instead, there is a custom ResampleStream now that backs Stream:resample().
  It also performs linear interpolation but has constant memory requirements and works with factor-streams.
  Even for finite source streams and constant factors this implementation will be faster and more
  real-time safe.
* You cannot play backwards, due to missing buffering.
  This can still be done manually using IndexStream if necessary.

* the structure is highly platform-dependant and might even differ between 32-bit and 64-bit systems
* in particular this fixes EvdevStream on FreeBSD