Realise there's an old thread about building in Windows, but just wanted to point out a couple of problems I've been running into:
Latest official Windows distributions from qt.org are 5.15.2 for Qt 5 and 6.4.0 for Qt 6. Qt 5 does not come with QtMultimedia. Qt 6 comes with QtMultimedia as an option, and a really poor Qt 5 Compatibility Module. I bring this up because most of the sound IO won't work properly using the basic sound/mmsystem configuration.
Everything builds fairly well in Qt 5, provided you are careful about not mixing dependencies built for debug with release for things like fdk-aac, fftw3, qwt, speexdsp, winpcap, and zlib. If you do, MSVC throws a lot of complaints about library conflicts between msvcrt and msvcrtd. This becomes problematic when some of the libraries already come pre-built and can't be easily rebuilt locally. If you even try to make msvcrt the default, you may end up having things crash when it tries to read or write the ini file. It can be made to build and run, but doesn't work correctly because the bulk of the processing is dependent upon the QtMultimedia package.
So there are two (maybe three) options here: Get the baseline to work in Qt 6 before it becomes obsolete and have working audio processing. Or, keep what's already there and just recode the sound/mmsystem modules to work properly in Qt 5.
So I've come to realise that the Qt5 Compatibility Module... isn't. Finding things like QRegExp being a problem when used in a way it doesn't expect and I'm sure there are other problems. There are other, deeper issues with a conflict between using namespace std, and _BYTE being rejected as ambiguous all over the place. So although this would be a better and longer term solution, it's a huge undertaking. The latter will be much, much less work but also has a limited shelf life once Qt 5 becomes so limited and devoid of the necessary parts that it's virtually obsoleted in Windows.
A potential third option is to rebuild everything in minGWin32, which is how I think I did it for Win xp some 20 years ago, but that would require me to re-read my notes on my web site and try to refresh my memory about everything I did in 2004. Also not an easy task at this stage in life. š
Comments? Have I missed anything?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One thing it would be nice: if we have a reproducible / downloadable
tool-chain to build Dream on Windows. Many people ask me this... and I
just say to install Linux as I have no patience to build a environment.
Btw, running Dream on WSL is not enough?
Rafael
On 11/13/22 17:55, Mark J. Fine wrote:
Realise there's an old thread about building in Windows, but just wanted
to point out a couple of problems I've been running into:
1.
LatestofficialWindowsdistributionsfromqt.orgare5.15.2forQt5and6.4.0forQt6.Qt5doesnotcomewithQtMultimedia.Qt6comeswithQtMultimediaasanoption,andareallypoorQt5CompatibilityModule.IbringthisupbecausemostofthesoundIOwon't work properly using the basic sound/mmsystem configuration.
2.
EverythingbuildsfairlywellinQt5,providedyouarecarefulaboutnotmixingdependenciesbuiltfordebugwithreleaseforthingslikefdk-aac,fftw3,qwt,speexdsp,winpcap,andzlib.Ifyoudo,MSVCthrowsalotofcomplaintsaboutlibraryconflictsbetweenmsvcrtandmsvcrtd.Thisbecomesproblematicwhensomeofthelibrariesalreadycomepre-builtandcan't be easily rebuiltlocally. If you even try to make msvcrt the default, you may end uphaving things crash when it tries to read or write the ini file. Itcanbemadetobuildandrun,butdoesn't work correctly because thebulk of the processing is dependent upon the QtMultimedia package.
So there are two (maybe three) options here: Get the baseline to work in
Qt 6 before it becomes obsolete and have working audio processing. Or,
keep what's already there and just recode the sound/mmsystem modules to
work properly in Qt 5.
So I've come to realise that the Qt5 Compatibility Module... isn't.
Finding things like QRegExp being a problem when used in a way it
doesn't expect and I'm sure there are other problems. There are other,
deeper issues with a conflict between |using namespace std|, and |_BYTE|
being rejected as ambiguous all over the place. So although this would
be a better and longer term solution, it's a huge undertaking. The
latter will be much, much less work but also has a limited shelf life
once Qt 5 becomes so limited and devoid of the necessary parts that it's
virtually obsoleted in Windows.
A potential third option is to rebuild everything in minGWin32, which is
how I think I did it for Win xp some 20 years ago, but that would
require me to re-read my notes on my web site and try to refresh my
memory about everything I did in 2004. Also not an easy task at this
stage in life. š
I could go the MSYS2 route, but would much rather go native (I've got ptsd trying to get nrsc5 and my python gui working in MSYS2, which drove me bonkers). I already have it running in Linux and on macOS alongside GQRX, but I have a lot of other Win-based tools like MultiPSK and SDR#, for using my AirSpy HF+. Dream would make a nice complement to those. Am using VB Cable to pipe from SDR# to MultiPSK (and later, Dream). Also, SDR# has a remote receiver mode where I can pull in the I/Q signals from someone's AirSpy or RTL_SDR from anywhere in the world over the internet. š
So I found a way to cmake and build several of the packages that were causing problems using MSVC, and have likewise been able to build and add sndfile and libFLAC. Can report that fftw, the Qtw graphics, and especially the demodulator and fdk-aac codec are now working properly using many of the sample capture files. The MSVCRT problem was narrowed down to using a pre-built fdk-aac.lib and .dll containing debug code in a release build.
So the only thing left to work on (he said, after messing with this for a few days now) is making sound/winmm work properly as a viable input in lieu of QtMultimedia. At least this will give me a fully operational Windows baseline.
I also want to add a dark theme that matches the user's environment for Win builds, because Qt doesn't natively support it in Windows... of course. Those glaring white Vista-like theme that Qt uses as the default is hurting my eyes.
Last edit: Mark J. Fine 2022-11-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Praise your work! Please let us know of the binaries for the Windows
build. Lots of people in Brazil waiting for the xDream Windows build (as
some friends call the Dream with xAAC support).
)
Rafael
On 11/14/22 05:19, Mark J. Fine wrote:
I could go the MSYS2 route, but would much rather go native (I've got
ptsd trying to get nrsc5 and my python gui working in MSYS2, which drove
me bonkers). I already have it running in Linux and on macOS alongside
GQRX, but I have a lot of other Win-based tools like MultiPSK and SDR#,
for using my AirSpy HF+. Dream would make a nice complement to those. Am
using VB Cable to pipe from SDR# to MultiPSK (and later, Dream).
So I found a way to cmake and build several of the packages that were
causing problems using MSVC, and have likewise been able to build and
add sndfile and libFLAC. Can report that fftw, the Qtw graphics, and
especially the demodulator and fdk-aac codec are now working properly
using many of the sample capture files. The MSVCRT problem was narrowed
down to using a pre-built fdk-aac.lib and .dll containing debug code in
a release build.
So the only thing left to work on (he said, after messing with this for
a few days now) is making sound/winmm work properly as a viable input in
lieu of QtMultimedia. At least this will give me a fully operational
Windows baseline.
I also want to add a dark theme that matches the user's environment for
Win builds, because Qt doesn't natively support it in Windows... of
course. Those glaring white Vista-like theme that Qt uses as the default
is hurting my eyes.
Hi Mark, thanks for a REALLY helpful situation report. Iām afraid I failed abysmally the last time I tried building on Windows.
By contrast a MacOs build using a homebrew recipe worked like a dream.
QtMultimedia used to be in Qt5 ā have they changed that? Oh dear.
We had huge problems moving from Qt2 to Qt3 and pretty much every major version. If we could find a Windows savvy volunteer to help that would be wonderful.
With the fantastic work Ollie has done recently on Dream, it would be great to do a release. If we can make this a Qt6 migration too, and try to restore cross platform simplicity, that would be even better.
Realise there's an old thread about building in Windows, but just wanted to point out a couple of problems I've been running into:
Latest official Windows distributions from qt.org are 5.15.2 for Qt 5 and 6.4.0 for Qt 6. Qt 5 does not come with QtMultimedia. Qt 6 comes with QtMultimedia as an option, and a really poor Qt 5 Compatibility Module. I bring this up because most of the sound IO won't work properly using the basic sound/mmsystem configuration.
Everything builds fairly well in Qt 5, provided you are careful about not mixing dependencies built for debug with release for things like fdk-aac, fftw3, qwt, speexdsp, winpcap, and zlib. If you do, MSVC throws a lot of complaints about library conflicts between msvcrt and msvcrtd. This becomes problematic when some of the libraries already come pre-built and can't be easily rebuilt locally. If you even try to make msvcrt the default, you may end up having things crash when it tries to read or write the ini file. It can be made to build and run, but doesn't work correctly because the bulk of the processing is dependent upon the QtMultimedia package.
So there are two (maybe three) options here: Get the baseline to work in Qt 6 before it becomes obsolete and have working audio processing. Or, keep what's already there and just recode the sound/mmsystem modules to work properly in Qt 5.
So I've come to realise that the Qt5 Compatibility Module... isn't. Finding things like QRegExp being a problem when used in a way it doesn't expect and I'm sure there are other problems. There are other, deeper issues with a conflict between using namespace std, and _BYTE being rejected as ambiguous all over the place. So although this would be a better and longer term solution, it's a huge undertaking. The latter will be much, much less work but also has a limited shelf life once Qt 5 becomes so limited and devoid of the necessary parts that it's virtually obsoleted in Windows.
A potential third option is to rebuild everything in minGWin32, which is how I think I did it for Win xp some 20 years ago, but that would require me to re-read my notes on my web site and try to refresh my memory about everything I did in 2004. Also not an easy task at this stage in life. š
This email, including attachments, is private and confidential and may contain personal views which are not the views of the Company unless specifically stated. If you have received this email in error, please notify the sender and delete it from your system. Any commercial terms contained in this e-mail or any attachments are for discussion purposes only, and do not constitute a legal agreement. No binding agreement will exist unless and until written execution of a long form contract signed by all parties to the agreement. Please note that the Company monitors e-mails sent or received. Further communication will signify your consent to this.
Julian - Yes, building on Mac and Linux is so much easier. Been a real long time since I could call myself being anything close to being Windows savvy, but I'm re-learning things... such as running Visual Studio Community (and having the right components, e.g., their version of Cmake will create VC project and solution files) instead of relying just on the bare bones Build Tools. Also re-learning the quirks of building Qt using Qt Creator on Windows, especially the way it caches things so you don't know if you're actually running what you just built or not.
So it may take me some time, but I will get something running... eventually. Think the best route is perhaps to get a working Qt 5 baseline to start from, then tackle Qt 6.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I may have been premature in my assessment regarding the QtMultimedia requirement. The quirks I thought were in Sound/WinMM turned out to be a hidden setting within SDR# that was doing strange things to the output audio. Having changed that, I'm in the process of trying to get audio from an active DRM signal (that's not broken Kuwait). At least I can pipe audio to it and correctly demodulate an AM signal in Dream now (Dream in AM, SDR# in USB with both sidebands covered) using the AM Receiver section... Had to adjust the latency in VB Cable to avoid any clicking, hopefully the 24-bit source is not a problem.
Continuing to look at the Sound Card settings, which crashes when you try to change the input or output source. It's annoying but not really critical when you can change the defaults within Windows itself.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Also while I'm at it, I noticed a few days ago that Kuwait had a near-perfect signal but couldn't generate any audio. When looking at the status output, it would say: zero output channels: 0 zero output channels: 0 Error condition is of unknown reason, or from a another module. Output buffer is invalid.
This was on a previously working version of Dream on a MBP.
This evening, while waiting for Romania to get strong enough on 6030, it was occasionally giving the same output on the new Windows box.
Just wondering: Is it possible that something has changed in DRM that no longer makes it compatible with standard fdk-aac? I would assume that if the FLAC files work, then the codec works the way it's supposed to. So has something changed on the transmission side of things?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I fear we have some bugs to fix in order Dream does not crashes often
with xAAC. But at least in my branch, xAAC decoding works fine when
signal is strong.
Rafael
On 11/16/22 06:20, Mark J. Fine wrote:
Also while I'm at it, I noticed a few days ago that Kuwait had a
near-perfect signal but couldn't generate any audio. When looking at the
status output, it would say:
|zero output channels: 0|
|zero output channels: 0|
|Error condition is of unknown reason, or from a another module. Output
buffer is invalid.|
This was on a previously working version of Dream on a MBP.
This evening, while waiting for Romania to get strong enough on 6030, it
was occasionally giving the same output on the new Windows box.
Just wondering: Is it possible that something has changed in DRM that no
longer makes it compatible with standard fdk-aac? I would assume that if
the FLAC files work, then the codec works the way it's supposed to. So
has something changed on the transmission side of things?
I've come to the conclusion that there's likely just too much selective fading on the channel and it's trying to decode trash. It runs through these things several times with a buffersize of just 1, then finally with about 850, then it does a total re-sync and starts over. Maybe I just need to be patient for better condx. Though in the interim I'm looking at my current sound, sourcedecoder, and receiver code to see if I can't get it closer to what Ollie has.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
And that's exactly what it was... excessive selective fading. Currently getting audio (between dropouts) from Romania on 9510 from Galbeni. Good signal but still a lot of fading. Worked well when doppler was hovering around .55-.56Hz.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Mark,
Could you share your Dream Windows build? I have an AirSpy HF+ and I
think I can receive some DRM signals here in Moscow. Btw, could we
directly support some of the most common SDR dongles directly in Dream?
Cheers,
Rafael
On 11/17/22 02:57, Mark J. Fine wrote:
And that's exactly what it was... excessive selective fading. Currently
getting audio (between dropouts) from Romania on 9510 from Galbeni. Good
signal but still a lot of fading. Worked well when doppler was hovering
around .55-.56Hz.
The last working Windows build I did (codewise) is updated in my branch: dream-mjf. It's before I started merging with Ollie's branch, but with I think it will work just fine when using the instructions I left for the dependencies in https://sourceforge.net/p/drm/discussion/compiling/thread/b1a40cb965/#16c2 above. Were you looking for a packaged executable?
Edit: Ollie was trying to add a Soapy interface. Just wondering if it makes more sense to try to wire-in a gnuradio interface, which might be better for the bulk of the SDRs out there. Whatever is used, I'd recommend using something that doesn't take complete control over the SDR, so you could use something like SDR# (Windows) or GQRX (linux/macos) in parallel, primarily for visualising the RF spectrum. It's so helpful to have that from a tuning perspective.
Last edit: Mark J. Fine 2022-11-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Word of caution though, as it still isn't 100%:
1. Still crashes if you try to change the soundcard input or output.
2. Still crashes if you try to load or change an external audio file. If you want to test with an input flac file you have to call it with -f <pathname> from the command window.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Word of caution though, as it still isn't 100%:
1. Still crashes if you try to change the soundcard input or output.
2. Still crashes if you try to load or change an external audio file. If
you want to test with an input flac file you have to call it with |-f
<pathname>| from the command window.</pathname>
I contacted the SDR# developer, Youssef on Twitter and it appears there's no specific plugin available for extending the API to outside packages yet, only things like CAT or NetRemote to have it control another local or remote radio or device - not control in the other direction. Going to look at developing a simple plugin for it that just sits there looping for tuning commands. Then we can have Dream do things like set SDR#'s mode to USB, bandwidth to 12kHz (or 20kHz), shift to 6kHz (or 10kHz), and then tune to any center frequency listed in a database. Think that might be a lot more efficient than using Hamlib on Windows and gives you an SDR display to boot. (says the guy who used to be a Hamlib developer...)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have access to an AirSpy HF+, a MSi. SDR (SDRPlay RSP 1 clone) and the
FunCubeDongle Pro+. Both work fine on both linux and windows (tested for
DRM reception also with he FhG MMPlayer).
Rafael
On 11/17/22 20:52, Mark J. Fine wrote:
I contacted the SDR# developer, Youssef on Twitter and it appears
there's no specific plugin available for extending the API to outside
packages yet, only things like CAT or NetRemote to have it control
another local or remote radio or device - not control in the other
direction. Going to look at developing a simple plugin for it that just
sits there looping for tuning commands. Then we can have Dream do things
like set SDR#'s mode to USB, bandwidth to 12kHz (or 20kHz), shift to
6kHz (or 10kHz), and then tune to any center frequency listed in a
database. Think that might be a lot more efficient than using Hamlib on
Windows and gives you an SDR display to boot. (says the guy who used to
be a Hamlib developer...)
Unfortunately, SDR# is a Windows app. Plugin build requires Visual Studio with .NET 7 Desktop.
Edit: But once I figure out what it needs to work, I can probably do something similar for GQRX for Linux/Mac (I would assume the Dream side would be the same). I could mention something to Clayton Smith who is currently maintaining it on github.
Edit2: Scratch that. I must be losing it. GQRX already has an API. I built it into Frequency Browser, so I already know what to do for that. Maybe I start with that for a test case.
Last edit: Mark J. Fine 2022-11-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Realise there's an old thread about building in Windows, but just wanted to point out a couple of problems I've been running into:
Latest official Windows distributions from qt.org are 5.15.2 for Qt 5 and 6.4.0 for Qt 6. Qt 5 does not come with QtMultimedia. Qt 6 comes with QtMultimedia as an option, and a really poor Qt 5 Compatibility Module. I bring this up because most of the sound IO won't work properly using the basic sound/mmsystem configuration.
Everything builds fairly well in Qt 5, provided you are careful about not mixing dependencies built for debug with release for things like fdk-aac, fftw3, qwt, speexdsp, winpcap, and zlib. If you do, MSVC throws a lot of complaints about library conflicts between msvcrt and msvcrtd. This becomes problematic when some of the libraries already come pre-built and can't be easily rebuilt locally. If you even try to make msvcrt the default, you may end up having things crash when it tries to read or write the ini file. It can be made to build and run, but doesn't work correctly because the bulk of the processing is dependent upon the QtMultimedia package.
So there are two (maybe three) options here: Get the baseline to work in Qt 6 before it becomes obsolete and have working audio processing. Or, keep what's already there and just recode the sound/mmsystem modules to work properly in Qt 5.
So I've come to realise that the Qt5 Compatibility Module... isn't. Finding things like QRegExp being a problem when used in a way it doesn't expect and I'm sure there are other problems. There are other, deeper issues with a conflict between
using namespace std, and_BYTEbeing rejected as ambiguous all over the place. So although this would be a better and longer term solution, it's a huge undertaking. The latter will be much, much less work but also has a limited shelf life once Qt 5 becomes so limited and devoid of the necessary parts that it's virtually obsoleted in Windows.A potential third option is to rebuild everything in minGWin32, which is how I think I did it for Win xp some 20 years ago, but that would require me to re-read my notes on my web site and try to refresh my memory about everything I did in 2004. Also not an easy task at this stage in life. š
Comments? Have I missed anything?
I don't think Qt5 will get obsoleted anytime soon. I would not spend
time on supporting Qt 6 right now.
I always build on Linux, but I'd be interested to help if you go mingw way:
https://github.com/Alexpux/MINGW-packages
One thing it would be nice: if we have a reproducible / downloadable
tool-chain to build Dream on Windows. Many people ask me this... and I
just say to install Linux as I have no patience to build a environment.
Btw, running Dream on WSL is not enough?
Rafael
On 11/13/22 17:55, Mark J. Fine wrote:
I could go the MSYS2 route, but would much rather go native (I've got ptsd trying to get nrsc5 and my python gui working in MSYS2, which drove me bonkers). I already have it running in Linux and on macOS alongside GQRX, but I have a lot of other Win-based tools like MultiPSK and SDR#, for using my AirSpy HF+. Dream would make a nice complement to those. Am using VB Cable to pipe from SDR# to MultiPSK (and later, Dream). Also, SDR# has a remote receiver mode where I can pull in the I/Q signals from someone's AirSpy or RTL_SDR from anywhere in the world over the internet. š
So I found a way to cmake and build several of the packages that were causing problems using MSVC, and have likewise been able to build and add sndfile and libFLAC. Can report that fftw, the Qtw graphics, and especially the demodulator and fdk-aac codec are now working properly using many of the sample capture files. The MSVCRT problem was narrowed down to using a pre-built fdk-aac.lib and .dll containing debug code in a release build.
So the only thing left to work on (he said, after messing with this for a few days now) is making sound/winmm work properly as a viable input in lieu of QtMultimedia. At least this will give me a fully operational Windows baseline.
I also want to add a dark theme that matches the user's environment for Win builds, because Qt doesn't natively support it in Windows... of course. Those glaring white Vista-like theme that Qt uses as the default is hurting my eyes.
Last edit: Mark J. Fine 2022-11-14
Hi Mark,
Rafael
On 11/14/22 05:19, Mark J. Fine wrote:
Hi Mark, thanks for a REALLY helpful situation report. Iām afraid I failed abysmally the last time I tried building on Windows.
By contrast a MacOs build using a homebrew recipe worked like a dream.
QtMultimedia used to be in Qt5 ā have they changed that? Oh dear.
We had huge problems moving from Qt2 to Qt3 and pretty much every major version. If we could find a Windows savvy volunteer to help that would be wonderful.
With the fantastic work Ollie has done recently on Dream, it would be great to do a release. If we can make this a Qt6 migration too, and try to restore cross platform simplicity, that would be even better.
Julian
From: discussion@drm.p.re.sourceforge.net discussion@drm.p.re.sourceforge.net on behalf of Mark J. Fine fineware@users.sourceforge.net
Date: Sunday, 13 November 2022 at 14:55
To: Julian Cable julian.cable@bbc.co.uk
Subject: [drm:discussion] Windows 11 Build Notes
Realise there's an old thread about building in Windows, but just wanted to point out a couple of problems I've been running into:
So there are two (maybe three) options here: Get the baseline to work in Qt 6 before it becomes obsolete and have working audio processing. Or, keep what's already there and just recode the sound/mmsystem modules to work properly in Qt 5.
So I've come to realise that the Qt5 Compatibility Module... isn't. Finding things like QRegExp being a problem when used in a way it doesn't expect and I'm sure there are other problems. There are other, deeper issues with a conflict between using namespace std, and _BYTE being rejected as ambiguous all over the place. So although this would be a better and longer term solution, it's a huge undertaking. The latter will be much, much less work but also has a limited shelf life once Qt 5 becomes so limited and devoid of the necessary parts that it's virtually obsoleted in Windows.
A potential third option is to rebuild everything in minGWin32, which is how I think I did it for Win xp some 20 years ago, but that would require me to re-read my notes on my web site and try to refresh my memory about everything I did in 2004. Also not an easy task at this stage in life. š
Comments? Have I missed anything?
Windows 11 Build Noteshttps://sourceforge.net/p/drm/discussion/compiling/thread/b1a40cb965/?limit=25#6746
Sent from sourceforge.net because julian.cable@bbc.co.uk is subscribed to https://sourceforge.net/p/drm/discussion/compiling/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/drm/admin/discussion/forums. Or, if this is a mailing list, you can unsubscribe from the mailing list.
This email, including attachments, is private and confidential and may contain personal views which are not the views of the Company unless specifically stated. If you have received this email in error, please notify the sender and delete it from your system. Any commercial terms contained in this e-mail or any attachments are for discussion purposes only, and do not constitute a legal agreement. No binding agreement will exist unless and until written execution of a long form contract signed by all parties to the agreement. Please note that the Company monitors e-mails sent or received. Further communication will signify your consent to this.
Julian - Yes, building on Mac and Linux is so much easier. Been a real long time since I could call myself being anything close to being Windows savvy, but I'm re-learning things... such as running Visual Studio Community (and having the right components, e.g., their version of Cmake will create VC project and solution files) instead of relying just on the bare bones Build Tools. Also re-learning the quirks of building Qt using Qt Creator on Windows, especially the way it caches things so you don't know if you're actually running what you just built or not.
So it may take me some time, but I will get something running... eventually. Think the best route is perhaps to get a working Qt 5 baseline to start from, then tackle Qt 6.
Well that part was easy enough...
I may have been premature in my assessment regarding the QtMultimedia requirement. The quirks I thought were in Sound/WinMM turned out to be a hidden setting within SDR# that was doing strange things to the output audio. Having changed that, I'm in the process of trying to get audio from an active DRM signal (that's not broken Kuwait). At least I can pipe audio to it and correctly demodulate an AM signal in Dream now (Dream in AM, SDR# in USB with both sidebands covered) using the AM Receiver section... Had to adjust the latency in VB Cable to avoid any clicking, hopefully the 24-bit source is not a problem.
Continuing to look at the Sound Card settings, which crashes when you try to change the input or output source. It's annoying but not really critical when you can change the defaults within Windows itself.
Just in case I forget, I've created a detailed listing of how to deal with building and installing each of the dependencies for Windows.
Also while I'm at it, I noticed a few days ago that Kuwait had a near-perfect signal but couldn't generate any audio. When looking at the status output, it would say:
zero output channels: 0zero output channels: 0Error condition is of unknown reason, or from a another module. Output buffer is invalid.This was on a previously working version of Dream on a MBP.
This evening, while waiting for Romania to get strong enough on 6030, it was occasionally giving the same output on the new Windows box.
Just wondering: Is it possible that something has changed in DRM that no longer makes it compatible with standard fdk-aac? I would assume that if the FLAC files work, then the codec works the way it's supposed to. So has something changed on the transmission side of things?
I fear we have some bugs to fix in order Dream does not crashes often
with xAAC. But at least in my branch, xAAC decoding works fine when
signal is strong.
Rafael
On 11/16/22 06:20, Mark J. Fine wrote:
I've come to the conclusion that there's likely just too much selective fading on the channel and it's trying to decode trash. It runs through these things several times with a buffersize of just 1, then finally with about 850, then it does a total re-sync and starts over. Maybe I just need to be patient for better condx. Though in the interim I'm looking at my current sound, sourcedecoder, and receiver code to see if I can't get it closer to what Ollie has.
And that's exactly what it was... excessive selective fading. Currently getting audio (between dropouts) from Romania on 9510 from Galbeni. Good signal but still a lot of fading. Worked well when doppler was hovering around .55-.56Hz.
Hi Mark,
Could you share your Dream Windows build? I have an AirSpy HF+ and I
think I can receive some DRM signals here in Moscow. Btw, could we
directly support some of the most common SDR dongles directly in Dream?
Cheers,
Rafael
On 11/17/22 02:57, Mark J. Fine wrote:
The last working Windows build I did (codewise) is updated in my branch: dream-mjf. It's before I started merging with Ollie's branch, but with I think it will work just fine when using the instructions I left for the dependencies in https://sourceforge.net/p/drm/discussion/compiling/thread/b1a40cb965/#16c2 above. Were you looking for a packaged executable?
Edit: Ollie was trying to add a Soapy interface. Just wondering if it makes more sense to try to wire-in a gnuradio interface, which might be better for the bulk of the SDRs out there. Whatever is used, I'd recommend using something that doesn't take complete control over the SDR, so you could use something like SDR# (Windows) or GQRX (linux/macos) in parallel, primarily for visualising the RF spectrum. It's so helpful to have that from a tuning perspective.
Last edit: Mark J. Fine 2022-11-17
Hi Mark. Indeed, I was writing about the compiled executable +
dependencies for trying out.
Rafael
On 11/17/22 16:39, Mark J. Fine wrote:
Ok.. Try this. Contains all the extra local dlls, including Qwt environment.
Word of caution though, as it still isn't 100%:
1. Still crashes if you try to change the soundcard input or output.
2. Still crashes if you try to load or change an external audio file. If you want to test with an input flac file you have to call it with
-f <pathname>from the command window.Thanks Mark! I'll take with these.
On 11/17/22 17:05, Mark J. Fine wrote:
If you're interested: On my branch, the dark mode portion is basically darkmode.cpp/h which is then called in DRMReceiver.cpp.
I contacted the SDR# developer, Youssef on Twitter and it appears there's no specific plugin available for extending the API to outside packages yet, only things like CAT or NetRemote to have it control another local or remote radio or device - not control in the other direction. Going to look at developing a simple plugin for it that just sits there looping for tuning commands. Then we can have Dream do things like set SDR#'s mode to USB, bandwidth to 12kHz (or 20kHz), shift to 6kHz (or 10kHz), and then tune to any center frequency listed in a database. Think that might be a lot more efficient than using Hamlib on Windows and gives you an SDR display to boot. (says the guy who used to be a Hamlib developer...)
Yay!
I can help develop and test on Linux. Any suggested library to use? I
know of gr-osmosdr:
https://osmocom.org/projects/gr-osmosdr/wiki
and SoapySDR:
https://github.com/pothosware/SoapySDR/wiki
I have access to an AirSpy HF+, a MSi. SDR (SDRPlay RSP 1 clone) and the
FunCubeDongle Pro+. Both work fine on both linux and windows (tested for
DRM reception also with he FhG MMPlayer).
Rafael
On 11/17/22 20:52, Mark J. Fine wrote:
Unfortunately, SDR# is a Windows app. Plugin build requires Visual Studio with .NET 7 Desktop.
Edit: But once I figure out what it needs to work, I can probably do something similar for GQRX for Linux/Mac (I would assume the Dream side would be the same). I could mention something to Clayton Smith who is currently maintaining it on github.
Edit2: Scratch that. I must be losing it. GQRX already has an API. I built it into Frequency Browser, so I already know what to do for that. Maybe I start with that for a test case.
Last edit: Mark J. Fine 2022-11-18