Hello, I spent a few hours to get dream 2.3 working on linux. I'm really only familiar with C# but the changes I made were simple enough that C++ wasn't really a problem.
I used r1378, ollie branch as a base as it had improvements but wasn't completely functional. I don't know how to use svn so temporarily chucked it up on github if you feel the changes are worth merging.
There are still a few things I need to look at, namely when switching SoapySDR input the program will hang, I had to run it using the -I and -O parameters. -I is weird and requires the colon too, for me that was -I "SoapySDR device #2: "
I know portaudio is also broken, but I fixed the gps and rig_model_t error, along with the dpkg-buildpackage being terribly out of date. Also when dream detects DRM it reopens the stream causing a crash, I fixed this by closing the stream first (not sure if that was the right approach, but it worked for me). I can decode xHE-AAC on linux now.
The transmitter also crashes because linux feeds it a mono stream which causes a null on the second channel which throws in the resampler. Haven't poked that one just yet.
Hi. Thanks for trying my branch and for your contributions! I've had a look at your commit and definitely need to incorporate some of the changes. The GPS-related stuff is different for different library versions - @jcable was going to have a look at that but I know he's very busy.
I've already changed the #include for tuner.h; I don't know how my build environment was finding it but I guess it's something to do with the include path.
I note that you changed a line to include "linux/sound.h". I've tried to abstract out the sound in/out a bit better, using a factory to create an object implementing the abstract CSoundInInterface interface. This replaces the old sound/sound.h file which used the preprocessor to provide the desired concrete class. However I accidentally left a #include in DRMReceiver.cpp, which is the one that you've changed to linux/sound.h. I corrected this in rev 1379 and it should correctly use linux/sound.h if appropriate. You should simply be able to delete that #include line.
The factory needs more work: in particular if Soapy is included it will always offer SoapySDR devices as the audio input, which is not what you want in the transmitter. Back in 2021 I had an approach in mind for that and will try to resurrect the idea.
I haven't tried with more than one SoapySDR device but I do have a second one on my desk so I will try to investigate.
Rev 1380, which I just committed, has the tuner.h fix and removes the colon from the end of the device name - I agree that was weird! I'll try to incorporate more of your changes where applicable later on.
Best wishes
Ollie.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks. I was also experimenting in getting the transmitter working but kept running into issues with the speex resampler, the codec initialises with 2 channels because of a faulty ternery that reads AM_MONO (i think), but then ran into issues elsewhere because one of the channels is never added to the array (CodecInfoL works but CodecInfoR is nullptr amd crashes). I am tempted to drop libfaac/faad and just use libfdk_aac, but as I said my c++ knowledge is lacking.
Is there a better way to get into contact or should I just keep ecperimenting and reporting back here :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Will do. I'll change my git so that the master branch is a direct copy of the snapshot zip, and then keep rebasing my darklight branch on top of it to keep up to date against the project until it's no longer needed :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK I've added some more of the changes from your git repo, and committed them (basically untested). I haven't touched the GPS or Hamlib stuff this time. I hope to look at that next week.
I'd prefer to use git too, but we'd want to co-ordinate any switchover with other developers.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello all. I've just committed Rev 1382, which can handle switching between different SoapySDR devices. I've only been able to test it with SDRPlay RSP1As. I'd be interested to hear whether it works for others!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi. Rev 1384 has more of your fixes in: specifically the ones for GPS. I realised that my problem was that I don't have libgps, so it was the fallback definitions that needed to change to match. These changes are in your git repo but weren't in the changes that had been applied to my branch.
I'm trying to understand the Hamlib issue. For some reason, rig_model_t was defined in DialogUtil.h. It feels like either this could be propagated from the hamlib headers (so it changes if they change), or should be hidden from the client code by the CRig abstraction. I'm not even sure how it avoids duplicate definition errors. Apparently there's no compilation unit that can see both definitions...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK: in rev 1385, I've tried completely removing the redefinition of rig_model_t from DialogUtil.h, and it compiles both with and without hamlib. Whatever purpose the typedef served, I don't think it's needed any more.
Re my earlier post: it turns out that it's ok (in C++) to multiply define a type using typedef, as long as the types agree.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Looks good, the only changes I have now is to allow 'dpkg-buildpackage -us -uc' to work, although I haven't yet tested if there is missing packages from a completely fresh install.
I'm also running debian/unstable and will also need to make sure there isn't anything I'm using that is missing in stable.
I think making the transmitter work is beyond my abilities but I was mainly interested in listening with an SDR, the only reason I started playing with the transmitter anyway was to test if the receiver was going to work, but it instantly crashes because it starts transmitting straight away. I have a hunch that leaving faac behind and just using libfdk might be the solution because the error I kept hitting bubbles up from the insides of libfaac, it appears that faac-drm always requires two channels and the transmitter only feeds it one
EDIT: The combined sound thing works great by the way!
Last edit: Christopher Andrews 2022-02-09
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello, I spent a few hours to get dream 2.3 working on linux. I'm really only familiar with C# but the changes I made were simple enough that C++ wasn't really a problem.
I used r1378, ollie branch as a base as it had improvements but wasn't completely functional. I don't know how to use svn so temporarily chucked it up on github if you feel the changes are worth merging.
https://github.com/godarklight/dream.git
There are still a few things I need to look at, namely when switching SoapySDR input the program will hang, I had to run it using the -I and -O parameters. -I is weird and requires the colon too, for me that was -I "SoapySDR device #2: "
I know portaudio is also broken, but I fixed the gps and rig_model_t error, along with the dpkg-buildpackage being terribly out of date. Also when dream detects DRM it reopens the stream causing a crash, I fixed this by closing the stream first (not sure if that was the right approach, but it worked for me). I can decode xHE-AAC on linux now.
The transmitter also crashes because linux feeds it a mono stream which causes a null on the second channel which throws in the resampler. Haven't poked that one just yet.
Hi. Thanks for trying my branch and for your contributions! I've had a look at your commit and definitely need to incorporate some of the changes. The GPS-related stuff is different for different library versions - @jcable was going to have a look at that but I know he's very busy.
I've already changed the #include for tuner.h; I don't know how my build environment was finding it but I guess it's something to do with the include path.
I note that you changed a line to include "linux/sound.h". I've tried to abstract out the sound in/out a bit better, using a factory to create an object implementing the abstract CSoundInInterface interface. This replaces the old sound/sound.h file which used the preprocessor to provide the desired concrete class. However I accidentally left a #include in DRMReceiver.cpp, which is the one that you've changed to linux/sound.h. I corrected this in rev 1379 and it should correctly use linux/sound.h if appropriate. You should simply be able to delete that #include line.
The factory needs more work: in particular if Soapy is included it will always offer SoapySDR devices as the audio input, which is not what you want in the transmitter. Back in 2021 I had an approach in mind for that and will try to resurrect the idea.
I haven't tried with more than one SoapySDR device but I do have a second one on my desk so I will try to investigate.
Rev 1380, which I just committed, has the tuner.h fix and removes the colon from the end of the device name - I agree that was weird! I'll try to incorporate more of your changes where applicable later on.
Best wishes
Ollie.
Thanks. I was also experimenting in getting the transmitter working but kept running into issues with the speex resampler, the codec initialises with 2 channels because of a faulty ternery that reads AM_MONO (i think), but then ran into issues elsewhere because one of the channels is never added to the array (CodecInfoL works but CodecInfoR is nullptr amd crashes). I am tempted to drop libfaac/faad and just use libfdk_aac, but as I said my c++ knowledge is lacking.
Is there a better way to get into contact or should I just keep ecperimenting and reporting back here :)
It's best to post here so that everyone can see the discussion. There's at least one other person playing with the dream-ollie branch.
Will do. I'll change my git so that the master branch is a direct copy of the snapshot zip, and then keep rebasing my darklight branch on top of it to keep up to date against the project until it's no longer needed :)
OK I've added some more of the changes from your git repo, and committed them (basically untested). I haven't touched the GPS or Hamlib stuff this time. I hope to look at that next week.
I'd prefer to use git too, but we'd want to co-ordinate any switchover with other developers.
Hello all. I've just committed Rev 1382, which can handle switching between different SoapySDR devices. I've only been able to test it with SDRPlay RSP1As. I'd be interested to hear whether it works for others!
You might also like to try rev 1383, which should allow selection between SoapySDR inputs and sound inputs.
Hi. Rev 1384 has more of your fixes in: specifically the ones for GPS. I realised that my problem was that I don't have libgps, so it was the fallback definitions that needed to change to match. These changes are in your git repo but weren't in the changes that had been applied to my branch.
I'm trying to understand the Hamlib issue. For some reason,
rig_model_twas defined in DialogUtil.h. It feels like either this could be propagated from the hamlib headers (so it changes if they change), or should be hidden from the client code by the CRig abstraction. I'm not even sure how it avoids duplicate definition errors. Apparently there's no compilation unit that can see both definitions...OK: in rev 1385, I've tried completely removing the redefinition of rig_model_t from DialogUtil.h, and it compiles both with and without hamlib. Whatever purpose the
typedefserved, I don't think it's needed any more.Re my earlier post: it turns out that it's ok (in C++) to multiply define a type using
typedef, as long as the types agree.Looks good, the only changes I have now is to allow 'dpkg-buildpackage -us -uc' to work, although I haven't yet tested if there is missing packages from a completely fresh install.
I'm also running debian/unstable and will also need to make sure there isn't anything I'm using that is missing in stable.
I think making the transmitter work is beyond my abilities but I was mainly interested in listening with an SDR, the only reason I started playing with the transmitter anyway was to test if the receiver was going to work, but it instantly crashes because it starts transmitting straight away. I have a hunch that leaving faac behind and just using libfdk might be the solution because the error I kept hitting bubbles up from the insides of libfaac, it appears that faac-drm always requires two channels and the transmitter only feeds it one
EDIT: The combined sound thing works great by the way!
Last edit: Christopher Andrews 2022-02-09
How do I checkout the latest revision of the ollie branch?
tks