4

Scenario:

OS: raspbian buster

  1. I have an audio chain as follows USB Audio Input->arecord->named pipe->forked-daapd. In the present configuration, arecord and forked-daapd are both set up as standard systemd services.
  2. The goal is to send audio from a turntable to a network audio endpoint (Sonos).
  3. The arecord part of the pipe is a very simple "arecord -D plughw:1,0 -t wav -f cd /srv/music/phono-source"
  4. If I create the named pipe ("phono-source") with mkfifo and then launch the arecord and forked-daap services, everything appears to work as expected.
  5. If I leave the configuration running but "idle", ie turntable not in use, so assume effectively generating silence/noise, at some point later, the original named pipe object gets renamed to "phono-source-01" and a new conventional (not pipe) file "phono-source-02" gets created. arecord is now writing data to the new file, which grows in size at the expected rate.
  6. This had me baffled for a little while until I realized that the audio out would have reached the maximum size for a wav file. Leaving things running for a little while longer, this was sort of confirmed as when phono-source-02 reached 2147483692 bytes, output resumed to a new conventional file, phono-source-03.
  7. I was vaguely aware of a 2Gig limit on wav files, but I had assumed that was a physical file limit, and since I am writing to a pipe in this case that it would not apply - apparently not. The brute force approach here would be to terminate the arecord service after each album was played on the turntable and start it for the beginning of a new album.

Any suggestions on a strategy for avoiding this problem, either by doing something different with the pipe, or using an alternate audio grabber like sox?

Any thoughts?

Harvey Harrison
  • 41

1 Answers1

2

If you look at the source code for aplay.c/arecord.c, you'll see a table for formats like

static const struct fmt_capture {
    void (*start) (int fd, size_t count);
    void (*end) (int fd);
    char *what;
    long long max_filesize;
} fmt_rec_table[] = {
    {   NULL,       NULL,       N_("raw data"),     LLONG_MAX },
    {   begin_voc,  end_voc,    N_("VOC"),      16000000LL },
    /* FIXME: can WAV handle exactly 2GB or less than it? */
    {   begin_wave, end_wave,   N_("WAVE"),     2147483648LL },
    {   begin_au,   end_au,     N_("Sparc Audio"),  LLONG_MAX }
};

So you can see that WAV file size is restricted by design.

You may have more luck with -t raw (might need additional parameters for sample rate etc.) or -t au (Sun Sparc Audio file format), assuming forked-daapd can handle those (I've never used forked-daapd). LLONG_MAX is 9223372036854775807 on a 64-bit system, probably your file system complains before the file reaches that size.

If you do need WAV files, keep in mind that this format it has a header with the file size which can't be larger than 2 GB, so probably most implementations will have some kind of restriction wrt. max file size.

I don't know any particular implementation of an audio recorder that has a "streaming mode" (which actually would violate the WAV spec, to my knowledge) and ignores this on purpose. Which doesn't mean it doesn't exist.

dirkt
  • 32,309