After 5-10 seconds tuned to Radio Marti, 7345, I'm getting segmentation fault and Dream closes. This on Ubuntu 18.04.4 with pulseaudio. I tried dream -I pulse -O pulse.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It crashes more often with weak signals or interference decoding xHE-AAC. A work in progess. You can automatically restart with "while true; do (dream -I pulse -O pulse); done" if it helps.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Made these changes to my local [1334] branch and am happy to report that xHE-AAC works pretty well.
Was able to hear R. Marti on 7345 at ~0038 last night using my early 2013 MacBook Pro and external USB sound card via a JRC NRD-535D. This was even among some serious adjacent QRM by CRI. Was able to play the FM Gold sample file through it pretty easily, as well.
Only downside is that it needs a fairly stable signal. Too many transitions tend to make it crash, but making this work at all is pretty massive on its own.
Cheers, @KiwiSDR
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For the crashes: One quick thing to try is adding to my hack to fix the buffer overrun problem I had trouble with (I never found the source of the problem as it appears to be far away, like inside the codec possibly). Edit the change iMaxLenResamplerOutput *= 2; to iMaxLenResamplerOutput *= 8; or something. It doesn't hurt to make that buffer a bit larger.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've increased it from 2 to 8 in AudioSourceDecoder, so we'll see what happens.
That said, it could also be my setup. I'm using an external CM6206-based USB sound card as the line input. It has other issues with rapidly transitioning opens and closes, so it may also be the root of the problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Marti back on today (wasn't there yesterday). Initially it seemed to deal with the transitions ok and was hopeful, but then it gave up after a while. Unsure if making the buffer larger really helped.
That said I did notice it will only crash after it's lost audio, then tries to restart an audio stream... always on that leading event, so maybe it fails to open a stream (and buffer) but continues, causing a segfault.
Another thing I've noticed is the way the MM works in that info square, which may be another clue: Seems when it gets a long string, then a shorter one, the end of the longer string persists, like in this image. That 'OTICIAS.COM' at the end is a holdover from a previous display and shouldn't really be there.
Mark, I'm just re-reading these comments and noticed your mention of the corrupted text in the info display. I had noticed this in the KiwiSDR port of Dream and found that the C++ compiler I use wasn't generating good code for the range-for loop below. In src/TextMessage.cpp CTextMessageDecoder::ResetSegments() comment out the range-for loop and un-comment the commented out ordinary for-loop equivalent:
//for(inti=0; i < MAX_NUM_SEG_TEXT_MESSAGE; i++)//Segment[i].bIsOK=false;for(CTextMessSegmentsegment: Segment)segment.bIsOK=false;
Becomes:
for(inti=0; i < MAX_NUM_SEG_TEXT_MESSAGE; i++)Segment[i].bIsOK=false;//for(CTextMessSegmentsegment: Segment)segment.bIsOK=false;
Regards,
John
KiwiSDR
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Cheers. Makes sense.
I've recently updated qt-creator, which always breaks something in my build environment. It's always something stupid. Need to fix that first so I can rebuild. lol
Edit: Had to blow away the old build folder, rebuild from scratch, then copy back the runtime 'data' folder and Dream.ini file... Qt is always an adventure.
Last edit: Mark J. Fine 2020-08-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For various reasons I can't get Qt to work for me here (Mac environment). Otherwise I'd be able to do actual Dream builds. My observation is that after all these years Qt has, ironically, become the problem it was trying to solve..
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The one from the main Source Forge Dream DRM receiver site. It is on the Wiki on this site.
Tarmo,
I used the changes to dream.pro that you had posted earlier. I notice that your line 303 shows as line 306 on the dream.pro that I have.
Did you make any other changes to dream.pro besides those that kiwSDR had done?
--- dream.pro (revision 1338)
+++ dream.pro (working copy)
@@ -303,7 +303,7 @@
}
}
fdk-aac {
- DEFINES += HAVE_LIBFDK_AAC
+ DEFINES += HAVE_LIBFDK_AAC HAVE_USAC
LIBS += -lfdk-aac
HEADERS += src/sourcedecoders/fdk_aac_codec.h
SOURCES += src/sourcedecoders/fdk_aac_codec.cpp
Thank you,
-Zyg-
Thanks to Jason, Rafael, and Chris, I have managed to compile a working copy of the program.
Dream 2.2.1 was able to decode the VOA Radio Marti 7345 kHz DRM xHE-AAC mode for about an hour before it crashed.
It has been a very educational experience!
-Zyg-
Can that copy be made available for testing in India ??
After 5-10 seconds tuned to Radio Marti, 7345, I'm getting segmentation fault and Dream closes. This on Ubuntu 18.04.4 with pulseaudio. I tried dream -I pulse -O pulse.
It crashes more often with weak signals or interference decoding xHE-AAC. A work in progess. You can automatically restart with "while true; do (dream -I pulse -O pulse); done" if it helps.
Made these changes to my local [1334] branch and am happy to report that xHE-AAC works pretty well.
Was able to hear R. Marti on 7345 at ~0038 last night using my early 2013 MacBook Pro and external USB sound card via a JRC NRD-535D. This was even among some serious adjacent QRM by CRI. Was able to play the FM Gold sample file through it pretty easily, as well.
Only downside is that it needs a fairly stable signal. Too many transitions tend to make it crash, but making this work at all is pretty massive on its own.
Cheers, @KiwiSDR
For the crashes: One quick thing to try is adding to my hack to fix the buffer overrun problem I had trouble with (I never found the source of the problem as it appears to be far away, like inside the codec possibly). Edit the change
iMaxLenResamplerOutput *= 2;
toiMaxLenResamplerOutput *= 8;
or something. It doesn't hurt to make that buffer a bit larger.I've increased it from 2 to 8 in AudioSourceDecoder, so we'll see what happens.
That said, it could also be my setup. I'm using an external CM6206-based USB sound card as the line input. It has other issues with rapidly transitioning opens and closes, so it may also be the root of the problem.
Marti back on today (wasn't there yesterday). Initially it seemed to deal with the transitions ok and was hopeful, but then it gave up after a while. Unsure if making the buffer larger really helped.
That said I did notice it will only crash after it's lost audio, then tries to restart an audio stream... always on that leading event, so maybe it fails to open a stream (and buffer) but continues, causing a segfault.
Another thing I've noticed is the way the MM works in that info square, which may be another clue: Seems when it gets a long string, then a shorter one, the end of the longer string persists, like in this image. That 'OTICIAS.COM' at the end is a holdover from a previous display and shouldn't really be there.
Last edit: Mark J. Fine 2020-05-08
Mark, I'm just re-reading these comments and noticed your mention of the corrupted text in the info display. I had noticed this in the KiwiSDR port of Dream and found that the C++ compiler I use wasn't generating good code for the range-for loop below. In src/TextMessage.cpp CTextMessageDecoder::ResetSegments() comment out the range-for loop and un-comment the commented out ordinary for-loop equivalent:
Becomes:
Regards,
John
KiwiSDR
Cheers. Makes sense.
I've recently updated qt-creator, which always breaks something in my build environment. It's always something stupid. Need to fix that first so I can rebuild. lol
Edit: Had to blow away the old build folder, rebuild from scratch, then copy back the runtime 'data' folder and Dream.ini file... Qt is always an adventure.
Last edit: Mark J. Fine 2020-08-04
For various reasons I can't get Qt to work for me here (Mac environment). Otherwise I'd be able to do actual Dream builds. My observation is that after all these years Qt has, ironically, become the problem it was trying to solve..
Just like Java and wx-widgets were the great multi-platform hope of the 90s.
I'm running on Catalina here if you need help. Takes some wrangling but I can do most baseline mods from the cvs.