Error: write EPIPE on use of trim effect

[hillct]

Sox seems to be exiting, or at least, the stdin stream is closing prematurely, whenever the following sox Options are used:

var soxOptions={ input: {type: 'mp3' }, output: {type: 'wav'}, effects: ['trim',10] };

Trimming any amount yields the same result. Bumping up the verbosity to -V3 yields no useful data with regard to a failing of the sox command line, but it's unclear whether this is an issue of Node's internal streams handling, something within Duplexer or sox-stream itself. The issue appears 100% reproducible on Linux and Mac though primary testing was done on Mac. Any guidance would be helpful. Thanks.

[ArtskydJ]

What happens if you remove the effects parameter?

---

If you're familiar with the command line, you can try this:

Try running this command in your console:

sox --type mp3 inputfile.wav --type wav output1.wav trim 10

If that works, then run this in your console:

sox --type mp3 inputfile.wav --type wav - trim 10 > output2.wav

If one or the other fails, then it is probably an issue with your input file (or sox).

If both commands work fine, then sox-stream is probably at fault.

[hillct]

First, the trim effect works normally (as expected) on the command line as does the trim effect with redirected output. I also tested command line piping of input into SOX, which works as expected. If I remove the trim effect, used within sox-stream, I get the expected behavior. In that regard I've tested volume and tempo effects which both work fine. This issue appears specific to the trim effect.

In attempting to debug this myself over the past week, I looked at some of the node stream setup options {close: false} etc but it's unclear to me how to successfully pass those options for a child_process instantiation. It seems that the child_process 'exit' event fires immediately after the EPIPE error is encountered. I've not yet fully tested the possibility that it's a subprocess memory issue, ie node --max-old-space-size as it may be the case that the trim effect requires that the entire input is loaded into memory as part of the trim transformation, as distinct from other transformations.

UPDATE: I have now tested the process with an allocation of 8GB to the node process via --max-old-space-size=8192 with no impact. My understanding is this command line arg to Node should allocate 8GB to each node process and subprocess, so running out of (allocated) memory is seemingly not the cause of this issue.