Happy new year! In the SNAPSHOTS folder in the files area you can find Windows, Linux and Mac binaries for a new snapshot of dream. Please try it out. I've been tearing my hair out trying to get it to compile on windows so there is a rough 64-bit one there but no 32-bit I'm afraid.
The linux binaries were made using docker on my Mac so I haven't run them but they should work.
This codebase is a branch off svn980 so it doesn't have any of the single window mode or DRM+ stuff in it - that was too buggy.
The major change is the built-in support for fdk-aac in the receiver.
This has fdk-aac v2 in it so the decoder does xHE-AAC but that won't work yet as I don't have any test streams.
The transmitter still depends on an external FAAC dll as the encoder in fdk-aac doesn't have any DRM support - it is missing the 960 transform and the error concealment code. The encoder doesn't do xHE-AAC at all.
The code also includes support for Qt Multimedia as a replacement for pulseaudio, etc. It isn't good enough yet so these builds use pulse on mac and linux and the original winmm on Windows.
Please raise tickets for all the bugs you find.
Julian
Last edit: Julian Cable 2018-12-31
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks. I've got a couple of those but I'll add yours too. I'm well on the way but the variable number of audio frames per audio superframe requires some significant re-architecting of dream's decoding event loop.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Tried installing it on Win 7 64-bit PC. I hit three errors:
1)wpcap.dll missing - error cleared by copying dll from DREAM 2.1.1 folder
2)packet.dll missing - error cleared by copying dll from DREAM 2.1.1 folder
On another win 7 PC I installed the dll from a download on https://www.winpcap.org/install/default.htm.
3)no Qt platform plugin could be initialised - web indicates that qwindows.dll is missing but my attempts to understand and fix this error have failed.
I am really pleased that development of DREAM has started again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Stefano,
I found many copies of qwindows.dll on my PC in OneDrive, Welle.io DAB software, etc. I copied the biggest dll to the DREAM folder but it is not found by the application. The DREAM application is looking for the Qt platform plugin in the folder specified by the PATH variable in Windows.
I am not 100% sure that qwindows.dll is the missing plugin.
Good Hunting, Kevin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Tried installing it on Win 10 64-bit PC. I hit the same three errors:
1)wpcap.dll missing - error cleared by copying dll from DREAM 2.1.1 folder
2)packet.dll missing - error cleared by copying dll from DREAM 2.1.1 folder
Used files from dream-2.1.1-win32-svn808-df
3)no Qt platform plugin could be initialised... I don't know what version QT or plugin to install.
I would like to assist with testing and I am instersted in xHE-aac funtionality. I have a bench test setup using ettus USRP1 and SPARK software in trial mode for transmit and a LimeSDR for reception... So would use the DREAM in the last step to decode DRM.
Is there an up to date step by step for compiling in Windows? I see some information on old versions...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The same error message on my Windows 10 64 like Kevin and Douglas are reporting:
"...no Qt platform plugin could be initialised"
Any advice or suggestions will be greatly appreciated
Thorsten
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi - I'm concentrating on trying to get the dream2018 branch stable and released. This uses the fdk for HE-AAC but not for xHE-AAC. That's looking good on MacOS and Linux and I'm just about to test it on Windows.
Once that's done I'll get back to the xHE-AAC decoding.
This needs a major change to the received decoding chain because xHE-AAC frames are asynchronous to the DRM superframe so a different buffering approach is needed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just tried the latest windows snapshot and I don't think its worth playing with. It decodes our flac samples but doesn't detect the fdk codec although its built in.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I successfully compiled v2.2.1 on Linux Mint 19.1. Using test DRM files that worked with version 2.2-svn1021, I get an annoying flutter (constant, a few Hz) in the decoded audio. Is this caused by libfaad2 v2.8?
The repository offers no other version of this library.
What is the story here? Is libfaad2 v2.8 defective and likely to be fixed in the future? Or, is Dream 2.2.1 just incompatible with libfaad2 v2.8 and therefore obsolescent?
Last edit: jcoles 2019-04-25
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not sure. I'll try and upload a libfaad_drm.so file for you to test. We didn't change anything in Dream to cause an incompatibility. Once linux distros have fdk-aac v2 we will move to that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A significant difference with earlier version 2.2-svn1021 is in the reported loading of libraries when the program starts. Version 2.2-svn1021 reports:
Got FAAC library
Got Opus library
But this latest version 2.2.1 reports:
Got FAAD2 library
Got FAAC library
It appears that the earlier version actually decodes with FAAC. Is that possible?
Looking at the WAV file output for the newer version, it is clear to me that the decoding cuts in and out, 20ms of audio then 20ms of silence.
Your faad package made no difference.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Odd. It should still say 'Got Opus library' when appropriate but it might not if Opus is linked in rather than being discovered at run time. FAAC is the encoder for use in the transmitter. I uploaded the wrong library - you needed libfaad2 not faad2. But actually I think its newer FAAC that's broken not FAAD2 so I'm not sure where the stuttering is coming from.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The tar.gz available today (25 April 2019) is twice the size of yesterday's. What has changed? The Changelog in the archive has not been updated since version 1.14.
The performance is the same as yesterday. The audio flutters as if the sound is rapidly cutting in and out. The program repeatedly reports "underrun". I have found no change to audio settings that changes this.
I should also note that the Input PSD and Input Spectrum displays don't work, although the Waterfall does. The broken red line ("DC frequency") is in the right place, but the spectrum display is a single vertical line at 0kHz.
For the first time today, I noticed the .deb package. Unfortunately, it requires libqt5core5a 5.11. The version available to me is 5.9.5. Which Linux distribution do you use?
Thanks for your efforts.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've fixed the Input Spectrum and Input PSD plots in svn 1298 and updated the source tarball. Thanks for spotting that. FYI it was caused by bad edits removing warnings about old style casts and I needed to move the int to float conversions around a bit.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't understand. You're referring me to a posting from February that mentions the exact problem that I have. There's no solution there that I can see. Has Dream 2.2 been stuttering since February? It's unusable with the stuttering. Why even put it up?
It seemed to have stopped.
When? Yesterday's build fixed the Input Spectrum and Input PSD plots, but the stuttering remains. By the way, it's confusing that your updated files on SourceForge have the same name as previously. Why not add a numeric suffix that increments each time?
The sample recording you mention is one of the files I already use. "See if its the same as real audio input?" I've tried using SMPlayer to play the sample file into the Dream audio input. The Dream audio stutters exactly as it does when I play the file with the Dream -f option.
Last edit: jcoles 2019-04-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks, that's what I wanted to know. Sorry about the numbering - I really thought I'd got all this fixed when I created the 2.2 folder and then it all seemed to fall apart. It's very frustrating. I know its stuff I've done but it's really confusing. None of these problems happen on my main machine which is a mac. My windows/linux machine is very old and slow.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I haven't had any success with the Windows-full version. With a clean install I had errors for mssing dlls: wpcap.dll, packet.dll and api-ms-win-core-synch-l1-2-1. I put copies of these into the same directory as the extracted files. The next error was 'application was unable to start correctly 0xc000007b'.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Happy new year! In the SNAPSHOTS folder in the files area you can find Windows, Linux and Mac binaries for a new snapshot of dream. Please try it out. I've been tearing my hair out trying to get it to compile on windows so there is a rough 64-bit one there but no 32-bit I'm afraid.
The linux binaries were made using docker on my Mac so I haven't run them but they should work.
This codebase is a branch off svn980 so it doesn't have any of the single window mode or DRM+ stuff in it - that was too buggy.
The major change is the built-in support for fdk-aac in the receiver.
This has fdk-aac v2 in it so the decoder does xHE-AAC but that won't work yet as I don't have any test streams.
The transmitter still depends on an external FAAC dll as the encoder in fdk-aac doesn't have any DRM support - it is missing the 960 transform and the error concealment code. The encoder doesn't do xHE-AAC at all.
The code also includes support for Qt Multimedia as a replacement for pulseaudio, etc. It isn't good enough yet so these builds use pulse on mac and linux and the original winmm on Windows.
Please raise tickets for all the bugs you find.
Julian
Last edit: Julian Cable 2018-12-31
Hello all,
Long time lurker, first time poster. With regard to sample streams from xHE-AAC transmissions - there is one such signal receiveable on a remote KiwiSDR in New Delhi at http://newdelhi.twrmon.net:8073/ on the frequency of 828 kHz. It also provides a possibility to record and download recordings, including that of the I/Q signal. Here's an example recording I made using that remote SDR: https://www.dropbox.com/s/fcylqg16mdfej2j/newdelhi.twrmon.net_2019-01-26T09_25_07Z_828.00_iq.wav?dl=0
For it to work in Dream, the Dream audio channel should be set to I/Q Pos Split.
Thanks. I've got a couple of those but I'll add yours too. I'm well on the way but the variable number of audio frames per audio superframe requires some significant re-architecting of dream's decoding event loop.
Tried installing it on Win 7 64-bit PC. I hit three errors:
1)wpcap.dll missing - error cleared by copying dll from DREAM 2.1.1 folder
2)packet.dll missing - error cleared by copying dll from DREAM 2.1.1 folder
On another win 7 PC I installed the dll from a download on https://www.winpcap.org/install/default.htm.
3)no Qt platform plugin could be initialised - web indicates that qwindows.dll is missing but my attempts to understand and fix this error have failed.
I am really pleased that development of DREAM has started again.
HI Julian and Kevin;
I am too very happy to see this development.
I can't find qwindows.dll anywhere for single download. Kevin, how did yo solve this problem - if you did solve it ?
Cheers, Stefano.
Hi Stefano,
I found many copies of qwindows.dll on my PC in OneDrive, Welle.io DAB software, etc. I copied the biggest dll to the DREAM folder but it is not found by the application. The DREAM application is looking for the Qt platform plugin in the folder specified by the PATH variable in Windows.
I am not 100% sure that qwindows.dll is the missing plugin.
Good Hunting, Kevin
Sorry for the delay. I'll answer this tomorrow. I'll borrow a windows PC.
Julian
I found the same result as Kevin,
Tried installing it on Win 10 64-bit PC. I hit the same three errors:
1)wpcap.dll missing - error cleared by copying dll from DREAM 2.1.1 folder
2)packet.dll missing - error cleared by copying dll from DREAM 2.1.1 folder
Used files from dream-2.1.1-win32-svn808-df
3)no Qt platform plugin could be initialised... I don't know what version QT or plugin to install.
I would like to assist with testing and I am instersted in xHE-aac funtionality. I have a bench test setup using ettus USRP1 and SPARK software in trial mode for transmit and a LimeSDR for reception... So would use the DREAM in the last step to decode DRM.
Is there an up to date step by step for compiling in Windows? I see some information on old versions...
I built the dream2019 branch and tried xhe-AAC transmissions from india. In most cases it produces a segmentation fault or Floating point exception .
The same error message on my Windows 10 64 like Kevin and Douglas are reporting:
"...no Qt platform plugin could be initialised"
Any advice or suggestions will be greatly appreciated
Thorsten
Hi - I'm concentrating on trying to get the dream2018 branch stable and released. This uses the fdk for HE-AAC but not for xHE-AAC. That's looking good on MacOS and Linux and I'm just about to test it on Windows.
Once that's done I'll get back to the xHE-AAC decoding.
This needs a major change to the received decoding chain because xHE-AAC frames are asynchronous to the DRM superframe so a different buffering approach is needed.
Thank you for the snapshots although I do not get any audio routed into these.
A blessed weekend ahead !
I just tried the latest windows snapshot and I don't think its worth playing with. It decodes our flac samples but doesn't detect the fdk codec although its built in.
I think this is now stable. It was REALLY hard getting a Windows build. I'll start uploading to the new 2.2 folder.
I successfully compiled v2.2.1 on Linux Mint 19.1. Using test DRM files that worked with version 2.2-svn1021, I get an annoying flutter (constant, a few Hz) in the decoded audio. Is this caused by libfaad2 v2.8?
The repository offers no other version of this library.
What is the story here? Is libfaad2 v2.8 defective and likely to be fixed in the future? Or, is Dream 2.2.1 just incompatible with libfaad2 v2.8 and therefore obsolescent?
Last edit: jcoles 2019-04-25
I'm not sure. I'll try and upload a libfaad_drm.so file for you to test. We didn't change anything in Dream to cause an incompatibility. Once linux distros have fdk-aac v2 we will move to that.
A significant difference with earlier version 2.2-svn1021 is in the reported loading of libraries when the program starts. Version 2.2-svn1021 reports:
But this latest version 2.2.1 reports:
It appears that the earlier version actually decodes with FAAC. Is that possible?
Looking at the WAV file output for the newer version, it is clear to me that the decoding cuts in and out, 20ms of audio then 20ms of silence.
Your faad package made no difference.
Odd. It should still say 'Got Opus library' when appropriate but it might not if Opus is linked in rather than being discovered at run time. FAAC is the encoder for use in the transmitter. I uploaded the wrong library - you needed libfaad2 not faad2. But actually I think its newer FAAC that's broken not FAAD2 so I'm not sure where the stuttering is coming from.
I think I'll make an fdk-aac v2 .deb in a ppa and build against that.
The tar.gz available today (25 April 2019) is twice the size of yesterday's. What has changed? The Changelog in the archive has not been updated since version 1.14.
The performance is the same as yesterday. The audio flutters as if the sound is rapidly cutting in and out. The program repeatedly reports "underrun". I have found no change to audio settings that changes this.
I should also note that the Input PSD and Input Spectrum displays don't work, although the Waterfall does. The broken red line ("DC frequency") is in the right place, but the spectrum display is a single vertical line at 0kHz.
For the first time today, I noticed the .deb package. Unfortunately, it requires libqt5core5a 5.11. The version available to me is 5.9.5. Which Linux distribution do you use?
Thanks for your efforts.
I've fixed the Input Spectrum and Input PSD plots in svn 1298 and updated the source tarball. Thanks for spotting that. FYI it was caused by bad edits removing warnings about old style casts and I needed to move the int to float conversions around a bit.
FYI I just noticed I said this in another thread https://sourceforge.net/p/drm/discussion/compiling/thread/b6e5437beb/#3912
It seemed to have stopped. Can you try the https://sourceforge.net/projects/drm/files/samples/DRM%20sample%20recordings/DWwithJournaline_ModeB_10kHz.flac/download file and see if its the same as real audio input?
I don't understand. You're referring me to a posting from February that mentions the exact problem that I have. There's no solution there that I can see. Has Dream 2.2 been stuttering since February? It's unusable with the stuttering. Why even put it up?
When? Yesterday's build fixed the Input Spectrum and Input PSD plots, but the stuttering remains. By the way, it's confusing that your updated files on SourceForge have the same name as previously. Why not add a numeric suffix that increments each time?
The sample recording you mention is one of the files I already use. "See if its the same as real audio input?" I've tried using SMPlayer to play the sample file into the Dream audio input. The Dream audio stutters exactly as it does when I play the file with the Dream -f option.
Last edit: jcoles 2019-04-29
Thanks, that's what I wanted to know. Sorry about the numbering - I really thought I'd got all this fixed when I created the 2.2 folder and then it all seemed to fall apart. It's very frustrating. I know its stuff I've done but it's really confusing. None of these problems happen on my main machine which is a mac. My windows/linux machine is very old and slow.
I haven't had any success with the Windows-full version. With a clean install I had errors for mssing dlls: wpcap.dll, packet.dll and api-ms-win-core-synch-l1-2-1. I put copies of these into the same directory as the extracted files. The next error was 'application was unable to start correctly 0xc000007b'.