Add some support for reading from pipe

[davidavdav]

Hello,

I think it is great there is WAV file reading support in Julia.

For my current application I need to process audio data that is dynamically modified on the unix pipeline. Typically the modification happens with sox, and I want to add modifications (or read the pipeline) with Julia.

With a little trick you can read from an IO buffer that basically is a `cmd`

function Base.skip(::Base.Process, Uint64) end

or even from a pipeline(`cmd1`, `cmd2`) with an additional

function Base.skip(::Base.ProcessChain, Uint64) end

assuming we won't actually want to skip data on the pipeline.

However, when the cmd can't predict the wav length and can't seek back to fix it (as you can't on a unix pipeline), tricking readwav this way fails because it is trying to consume more data than available. E.g., with a cmd=`sox -t wav - -t wav - speed 1.1`

sox WARN wav: Length in output .wav header will be wrong since can't seek to fix it
ERROR: LoadError: EOFError: read end of file
Stacktrace:
 [1] unsafe_read(::Base.PipeEndpoint, ::Ptr{UInt8}, ::UInt64) at ./stream.jl:810

Sox actually warns about the trouble with the header being wrong, but still, since this is a still a common pattern in, e.g, Kaldi, it would be nice if wavread could be modified in a way that it can read from a pipeline, and fix the length afterwards.

I currently add a "sox -t wav - -t raw -r16000 -" on the pipeline I am reading from and then use reinterpret(Int16, read(pipeline([`$p` for p in pipe]...))) / 32768, effectively not using WAV.jl at all, which is a bit of a shame.

So support for reading from a pipeline would be great!

[dancasimiro]

Hmm, I wonder if you could base this solution on the existing ‘wavappend’ function. The goals seem similar.

[dancasimiro]

closing this issue for now, as the accompanying PR (#81) is closed.