iq_fm --wav switch creates wav that canno't be played with the aplay

[flux242]

Minor issue. I suppose something is wrong with the wav header added. The rs41mod decoder is able to understand the header but the standard linux tools. So as an example

../iq_svcl/iq_client --freq -0.3771 | ../iq_svcl/iq_fm --wav --lpbw 10 - 48000 32 --bo 16 | aplay -t wav

won't work. Workaround currently is to treat the stream as raw

../iq_svcl/iq_client --freq -0.3771 | ../iq_svcl/iq_fm --wav --lpbw 10 - 48000 32 --bo 16 | aplay -t raw -r 48000 -f S16_LE -c1

[rs1729]

iq_fmdoes not write the size/length. because it does not know the length. cf. https://github.com/rs1729/RS/issues/23#issuecomment-671896785

[rs1729]

Changed (test-branch)

--- a/demod/iq_svcl/iq_fm.c
+++ b/demod/iq_svcl/iq_fm.c
@@ -180,7 +180,7 @@ static float write_wav_header(pcm_t *pcm) {
     }

     fwrite("data", 1, 4, fp);
-    data = 0; // datasize
+    data = 0xFFFFFFFF; // datasize unknown
     fwrite(&data,  1, 4, fp);

Should play streams now. The actual size/length can later be repaired:

sox --ignore-length file_nolen.wav file.wav

[flux242]

hm, sox writes a value there nevertheless

00000000  52 49 46 46 24 f0 ff 7f  57 41 56 45 66 6d 74 20  |RIFF$...WAVEfmt |
00000010  10 00 00 00 01 00 01 00  80 bb 00 00 00 77 01 00  |.............w..|
00000020  02 00 10 00 64 61 74 61  00 f0 ff 7f 00 00 00 00  |....data........|

7FFFF024 7FFFF000

[flux242]

sorry, posted before reading your comment above. Thanks

[flux242]

but note that sox treat 32 bits length field as a signed integer

[rs1729]

I know, I'm not sure what the right value would be to indicate a stream of unknown length, but 0xFFFFFFFF seems to work with aplay and audacity. Seems like it is enough to write the data length.

[flux242]

yep, seems to work now