windytan / slowrx Goto Github PK

Do you have plan to upgrade the code base for C++11?

After running for a few days, slowrx will suddenly freeze saying "Receiving FSK ID...". The time elapsed before freeezing appears to be highly variable. It doesn't freeze completely but the receiving and decoding images freezes up and the program must be restarted.

When decoding a PD image (in my case PD180) I get a roughly half height image:

Something I can't get my head around in the math:
The spec says "COLOR SCAN TIMES (Y, R-Y, B-Y)" for PD180 is 183.04ms.
183.04 / 640 = 0.286, as you have listed in modespec.c
/but/
the spec then says the sequence is Y(odd), R-Y, B-Y, Y(even). Wouldn't that mean there's a whole extra line not being accounted for somewhere?

I was experimenting with the Pasokon P5 mode when I managed to generate such a WAV file that repeatedly crashed the FSK decoder when being played through the ALSA loopback. Since some variables were optimized out, I recompiled without -O3 and got the following.

Waiting for header
  VIS 114 (72h) @ +0 Hz
  ==== Pasokon P5 ====
  getvideo @ 44100,0 Hz, Skip 0, HedrShift +0 Hz

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffdecd7700 (LWP 5660)]
0x00000000004084c0 in GetFSK (dest=0x7fffdecd6c40 "") at fsk.c:49
49   for (i = 0; i < 970; i++) fft.in[i] = pcm.Buffer[pcm.WindowPtr+i- 485] * Hann[i];
(gdb) p i
$1 = 0
(gdb) p pcm
$2 = {handle = 0x92bf50, Buffer = 0x92c120, WindowPtr = 58, BufferDrop = 0}

As it can be seen above, WindowPtr is 58, i is 0, so the body of the for loop tries to access the 58+0-485=-427 index in the array, which causes segmentation fault. I couldn't manage to get it crash with Pasokon P3 using the same FSK sequence.

Since I didn't fully understand what was going on in the FSK decoder (with that -485 offset and other things) to fix this negative addressing, I report it here, the original image and the WAV file can be downloaded in a 20MB 7zip archive from http://vsza.hu/p5crash.7z and latter was generated from the former by executing the following command.

$ python -m pysstv --rate 44100 --fskid P5TEST --chan 2 \
    --mode PasokonP5 rgb640x496.jpg p5.wav

Any chance this would run ok on Unix?

This would be lovely if it could take input from a pipe, so that it could be used from rtl_sdr or other software-defined radio utilities without having to play with alsa or jack to reroute audio...

my c++ foo is nil, though.