I am having trouble receiving signals with Dream, Version 2.2.1, revision 1352. Compiled with alsa.
I am running DietPi/Debian Bullseye 64 bit on a Raspberry Pi 4B.
I have Qt 5.15.2, Hamlib 4.1.
When I start dream with the command from the ~/dream directory, ./dream -I pulse -O pulse
it runs and at the start of the terminal output I see:
Got FAAD2 library
Got FAAC library
When I tune gqrx to a DRM signal on USB, 10 KHz wide and route it with a virtual audio cable to Dream, I can see the signal. In the evaluation dialogue, I can see the status of the reception. When the SNR gets somewhere above 12 dB, Dream suddenly quits, presumably when it starts to decode the audio.
The terminal output right after alsa is initialized:
CSoundCardSelMenu::OnSoundOutDeviceChanged pulse
output device changed in trx pulse
Working thread started
initrec 1280
DRMDialog eventUpdate
alsa init done
DecOpen sample rate 48000
initplay 38400
DecOpen sample rate 48000
DecOpen sample rate 48000 stack smashing detected : terminated
Aborted
Dream is very sensitive to which audio interface is chosen.
It crashes on startup only if I specify a valid audio device in the run command. Choosing any device in the menus will cause it to crash.
The only way I was able to get Dream to run with audio is to compile with alsa (qmake CONFIG+=alsa CONFIG+=sound) and to start it with the command, ./dream -I pulse -O pulse
I can to to AM (analog) and hear the audio from gqrx fed through Dream, so I think my audio interfaces are working.
Anything I am doing wrong?
----Steve
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've seen this happen, but only when using a specific codec (xHE-AAC) and a specific station (R. Marti) under rapid fading conditions. No idea what causes it though.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The only DRM station I have been able to find here in the USA is BBC WorldService 3955kHz at 04:00 UTC.
The station is relatively steady in strength, but normally too weak to decode. I do get the station information, which includes "16.92 kbps EEP AAC+ Mono" and in another place, adds "AFS", but when the signal reaches about 14 dB SNR, it crashes. This happens every time and I have never gotten any decoded audio. Could the station actually be using another codes such as xHE-AAC? Does Dream work with that?
The BBC doesn't have much online except a 2 year old schedule that doesn't include frequencies.
---Steve
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
BBC uses AAC+, which is a little different than xHE-AAC.
I have decoded several stations using AAC+ so it really shouldn't be that. It could be that for some reason your build either can't find the codec to decode, is having trouble buffering data or using the codec. 12-14db is usually the threshold of when audio can be generated. The status messages you are seeing are the beginnings of that process.
When it crashed in my earlier post, I had installed the newer faad2-2.8.8 and faac-1.30 from source.
./configure --enable-shared --without-xmms --with-drm --without-mpeg4ip
are floating point libraries an issue? I didn't see any reference to floating point in the terminal output after the crashes.
Dream did recognize faad2 and faac on startup.
The faad2-2.7 and faac-1.28 procedures did not work for my system.
These packages are quite old and did not recognize my build system type.
As recommended in the errors in the install log, I download the most up to date version of the config scripts from http://savannah.gnu.org/cgi-bin/viewcvs/checkout/config/config/config.guess
and http://savannah.gnu.org/cgi-bin/viewcvs/checkout/config/config/config.sub
The instruction: "cp include/neaacdec.h ../dream/libs" did not work because the directory in ~/dream is named lib.
It copied to a file named libs in the dream directory.
Instead, I did this from the ~/dream directory:
cp ~/faad2-2.7/include/neaacdec.h ~/dream/lib
mkdir libs
cp ~/faad2-2.7/include/neaacdec.h ~/dream/libs
After dream was built, when it was run, it said:
No usable FAAD2 aac decoder library found
No usable FAAC aac encoder library found
Then I went back to the faad2-2.7 and faac-1.28 directories and did:
sudo make install
sudo ldconfig
Recompiled dream
When dream was run, it said
No usable FAAD2 aac decoder library found
Got FAAC library
It found FAAC but not FAAD2.
I uninstalled faad2-2.7 and faac-1.28, then installed the compiled faad2-2.8.8 and faac-1.30.
dream now recognizes both FAAD2 and FAAC without recompiling.
It looks like I need to find a way to install that works!
----Steve
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok. So I may have partially steered you wrong. I'm using faad2-2.8.8 and faac-1.29.9.2 (both provided by Homebrew on a MBP), and faad2-2.8.8 seems to already include a libfaad_drm library built (libfaad_drm.a, libfaad_drm.dylib, libfaad_drm.2.dylib).
Considering Macs use .dylib vice .lib, is that similar to what your distribution has as well? If so, the codec thing may be a moot point, and we can move on to how the output is created/used: malloc/memory issue? device permissions issue? Trying to think what else it could be.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With the compiled version, I found these files:
Installed Program: faad (/usr/local/bin/faad)
Installed Library: libfaad.so and libfaad_drm.so
/usr/local/lib/libfaad.so.2.0.0
/usr/local/lib/libfaad.a
/usr/local/lib/libfaad.la
/usr/local/lib/libfaad_drm.so.2.0.0
/usr/local/lib/libfaad_drm.a
/usr/local/lib/libfaad_drm.la
I don't know if there was a copy of faad.h or neaacdec.h anywhere at the time it was crashing.
However, I do find them now. The dates are from the time I installed the compiled faad2-2.8.8 version again. I have tried what seems like everything.
/usr/local/include/faad.h
/usr/local/include/neaacdec.h
With the packager version,
I found these files:
/usr/bin/faad /usr/include/faad.h (didn't look for neaacdec.h)
I have found that Dream is very sensitive about the audio interfaces, crashing mostly on interfaces that actually exist. See my first post.
I can go to the AM dialogue and get audio passthrough from the input provided by gqrx.
----Steve
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
.dylib is the MacOS (FreeBSD?) equivalent of .lib, so you wouldn't see them in any Linux distribution.
I am starting to think it's something to do with the internal buffering. I made some changes in 1352 in this branch. I had a special case with a sketchy external USB-sound card that was having buffering problems and locking up on specific capture events. You can download a snapshot from a page at that link.
Maybe see if that fixes your problem as well? You may have to re-apply the fixes from that changes.txt, since I haven't applied them to that branch yet (but I really should at some point). I really should sync my local tree, since it's been ages...
Just so you know, I also use gqrx with an Airspy HF+ Discovery and am able to pipe gqrx through a virtual cable to Dream just fine using my reworked build. Might be the best place to start.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Does this mean that it isn't even using the AAC codecs that were installed?
I went to your web page and clicked Download Snapshot. I got drm-code-r1352-branches-dream-mjf.zip
I compiled with
qmake CONFIG+=alsa CONFIG+=sound
make -j4
I ran the program from the install directory
$ ./dream -I pulse -O pulse
Got FAAD2 library
Got FAAC library
qmake output, no codecs mentioned:
Info: creating stash file /home/dietpi/dream/.qmake.stash
Project MESSAGE: Qt 5 release GUI mode
Project MESSAGE: building on Linux
Project MESSAGE: with opus
Project MESSAGE: with libsndfile
Project MESSAGE: with libspeexdsp
Project MESSAGE: with hamlib
Project MESSAGE: with Qwt
Project MESSAGE: with alsa
Project MESSAGE: Qt modules core gui network xml widgets svg concurrent
This time, in System Evaluation, the Input PSD and Input Spectrum graphs worked. Before, they only had a blue line at the far left.
Waterfall input Spectrum worked before
Shifted PSD worked before
Audio Spectrum is blank
SNR Spectrum works, may have before
Dream crashed several time with stack smashing detected when high SNR was reached.
I have the output to the terminal. There is a lot there.
Bottom few lines:
initplay 38400
initrec 1280
DecOpen sample rate 48000
DecOpen sample rate 48000 stack smashing detected : terminated
Aborted
Are there useful debug messages that I can enable?
Any tests to try? I don't always get a good enough signal to start decoding.
There is some talk on the web that Raspberry Pi needs to have the non floating version of the codcecs. Was that pre RPI 4?
----Steve
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Lots of questions. Unfortunately I don't have many answers.
I assume you should continue using the packager versions, since it's seeing them. So I wouldn't change anything about the codecs right now.
Audio spectrum would be blank until it produces any audio.
To be honest, I'm at a loss as to why it doesn't work on your system. Maybe just run dream without the -I and -O switches, then manually set the sound card input and output options in Settings. It should save them for use the next time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With no dream.ini, starting dream with no audio interface specified:
Dream crashes on startup.
ALSA lib pcm_oss.c:377:(_snd_pcm_oss_open) Unknown field port
open error: Invalid argument
alsa CSoundOut::Init_HW playback, can't open oss
./dream -I default -O default
Dream runs
ALSA lib pcm_oss.c:377:(_snd_pcm_oss_open) Unknown field port
open error: Invalid argument
Signal input device has oss selected, signal output device has default.
In Pulse Audio Volume Control
There is no input device, but the output (default) is present.
Selecting pulse as the input device causes Dream to crash.
initrec 0
ALSA lib pcm_oss.c:377:(_snd_pcm_oss_open) Unknown field port
open error: Invalid argument
alsa CSoundIn::Init_HW record, can't open oss
...
QMutex: destroying locked mutex
Selecting pulse for output also crashes Dream.
./dream -I pulse -O default
Dream runs.
In Pulse Audio Volume Control
Input device is pulse and present, the output (default) is present.
Audio on Dream feed through AM works.
I should try this setup tonight.
I only have an hour or two of DRM per night, so this could take forever.
It's apparent that audio is an issue, but I do get audio output with the AM feature, so something is working.
Dream is very likely to crash with a valid audio device specified. Specifying an non existant audio device does not crash Dream.
Pulse works for input and output devices, only if they were specified on the command line. default works for audio output if specified from the command line.
I will change back to the system package AAC codecs.
----Steve
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not sure where you're located, but you could also try Kuwait in Arabic on 15110 from 0945-1325 UT. Can also try Romania on 7315 from 20-2100 (as in, right now), then 9620 from 21-22 UT.
Also getting biteXpress from Germany on 15785, which is a pleasant surprise. Hadn't heard them in ages.
Last edit: Mark J. Fine 2021-09-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am in Michigan, USA.
Nothing on 7315 now.
I did get Romainia RRI Galbeni TX1 on 7325 at 06:00 Z, got identification, not strong enough to decode.
Right now there is a very weak signal on 9620 21:00 Z
I am seeing 15785 so weak that I can barely make it out on the waterfall.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On biteXpress from Germany on 15785, never a good enough signal to decide, but I did get the identification briefly. It caused a Segmentation fault several times.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
biteXpress from Germany on 15785, never a good enough signal to decode, but it always caused a Segmentation fault eventually, but I got brief station info.
EEP xHE-AAC Stereo
FL xHE-AAC
(14.84 kbps) no codec available + MM... (was cut off in window)
Why don't I have a codec for this, but you do?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not sure, but xHE-ACC eventually crashes on mine after a rapid fade out/in anyway. First noticed that on R. Marti when they were doing DRM.
Again, I'm on a Mac, which is basically Free BSD, but with libraries supplemented by Homebrew, not a formal Linux release. There could be lots of differences between this and other distributions.
I'm going to try and sync up my local build directory with the branch today. Maybe there's something I did between then and now that adds the magic bullet.
Last edit: Mark J. Fine 2021-09-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So, apparently there are significant changes between the branch and my local version. I will try to sync it using svn but I need to remember how to do that... been forever since I did it so it may take some time to do.
Just in case, here's an executable diff/patch file of all the changes between my branch (-) and local (+) builds. First thing you'll notice is the addition of fdk-aac to the linux CONFIG, which may be part of the problem you're having.
My branch works well with fdk-aac for both xHE-AAC and AAC.
Rafael
On 9/28/21 4:06 PM, Mark J. Fine wrote:
So, apparently there are significant changes between the branch and my
local version. I will try to sync it using svn but I need to remember
how to do that... been forever since I did it so it may take some time
to do.
Just in case, here's an executable diff/patch file of all the changes
between my branch (-) and local (+) builds. First thing you'll notice is
the addition of fdk-aac to the linux CONFIG, which may be part of the
problem you're having.
Ok, so I think I've managed to sync things up so the branch matches my local build.
@rafael2k: I agree regarding xHE AAC. This has been a terrible year for me to do anything that requires detailed focus and attention.
Also, I wouldn't say I've taken over Dream development/maintenance as much as incorporated some changes in my own branch that keep it in-line with other related parts - some that I think you even provided. Frankly, I'm not smart enough about the way DRM works, nor the architecture of this software, which has evolved for over 20 years now. 😂
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes. The link to the branch should be the same, and it includes all of the updates for Qwt and Hamlib.
As for merging: I'm pretty sure Rafael and I only have access to our individual branches. It would be up to a project admin to review and merge, if deemed appropriate. Unfortunately, I'm pretty sure that the rudimentary way I was able to sync my changes (committing file by file, instead of issue by issue) didn't make it very easy for a reviewer to do their job.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am having trouble receiving signals with Dream, Version 2.2.1, revision 1352. Compiled with alsa.
I am running DietPi/Debian Bullseye 64 bit on a Raspberry Pi 4B.
I have Qt 5.15.2, Hamlib 4.1.
I was not able to successfully compile Dream until I patched the source files as specified in the discussion:
https://sourceforge.net/p/drm/discussion/compiling/thread/e2393d26d0/
The changes are detailed here:
https://sourceforge.net/p/drm/discussion/compiling/thread/e2393d26d0/6204/attachment/changes.txt
When I start dream with the command from the ~/dream directory, ./dream -I pulse -O pulse
it runs and at the start of the terminal output I see:
Got FAAD2 library
Got FAAC library
When I tune gqrx to a DRM signal on USB, 10 KHz wide and route it with a virtual audio cable to Dream, I can see the signal. In the evaluation dialogue, I can see the status of the reception. When the SNR gets somewhere above 12 dB, Dream suddenly quits, presumably when it starts to decode the audio.
The terminal output right after alsa is initialized:
CSoundCardSelMenu::OnSoundOutDeviceChanged pulse
output device changed in trx pulse
Working thread started
initrec 1280
DRMDialog eventUpdate
alsa init done
DecOpen sample rate 48000
initplay 38400
DecOpen sample rate 48000
DecOpen sample rate 48000
stack smashing detected : terminated
Aborted
Dream is very sensitive to which audio interface is chosen.
It crashes on startup only if I specify a valid audio device in the run command. Choosing any device in the menus will cause it to crash.
The only way I was able to get Dream to run with audio is to compile with alsa (qmake CONFIG+=alsa CONFIG+=sound) and to start it with the command, ./dream -I pulse -O pulse
I can to to AM (analog) and hear the audio from gqrx fed through Dream, so I think my audio interfaces are working.
Anything I am doing wrong?
----Steve
I've seen this happen, but only when using a specific codec (xHE-AAC) and a specific station (R. Marti) under rapid fading conditions. No idea what causes it though.
Thanks for your reply.
How do I know what codec is in use?
The only DRM station I have been able to find here in the USA is BBC WorldService 3955kHz at 04:00 UTC.
The station is relatively steady in strength, but normally too weak to decode. I do get the station information, which includes "16.92 kbps EEP AAC+ Mono" and in another place, adds "AFS", but when the signal reaches about 14 dB SNR, it crashes. This happens every time and I have never gotten any decoded audio. Could the station actually be using another codes such as xHE-AAC? Does Dream work with that?
The BBC doesn't have much online except a 2 year old schedule that doesn't include frequencies.
---Steve
BBC uses AAC+, which is a little different than xHE-AAC.
I have decoded several stations using AAC+ so it really shouldn't be that. It could be that for some reason your build either can't find the codec to decode, is having trouble buffering data or using the codec. 12-14db is usually the threshold of when audio can be generated. The status messages you are seeing are the beginnings of that process.
Are you using the standard Debian FAAD2 library or have you rebuilt it for use with DRM?
See https://drm.sourceforge.io/wiki/index.php/Instructions_for_building_the_AAC_decoder
When it crashed in my earlier post, I had installed the newer faad2-2.8.8 and faac-1.30 from source.
./configure --enable-shared --without-xmms --with-drm --without-mpeg4ip
are floating point libraries an issue? I didn't see any reference to floating point in the terminal output after the crashes.
Dream did recognize faad2 and faac on startup.
The faad2-2.7 and faac-1.28 procedures did not work for my system.
These packages are quite old and did not recognize my build system type.
As recommended in the errors in the install log, I download the most up to date version of the config scripts from
http://savannah.gnu.org/cgi-bin/viewcvs/checkout/config/config/config.guess
and
http://savannah.gnu.org/cgi-bin/viewcvs/checkout/config/config/config.sub
The instruction: "cp include/neaacdec.h ../dream/libs" did not work because the directory in ~/dream is named lib.
It copied to a file named libs in the dream directory.
Instead, I did this from the ~/dream directory:
cp ~/faad2-2.7/include/neaacdec.h ~/dream/lib
mkdir libs
cp ~/faad2-2.7/include/neaacdec.h ~/dream/libs
After dream was built, when it was run, it said:
No usable FAAD2 aac decoder library found
No usable FAAC aac encoder library found
Then I went back to the faad2-2.7 and faac-1.28 directories and did:
sudo make install
sudo ldconfig
Recompiled dream
When dream was run, it said
No usable FAAD2 aac decoder library found
Got FAAC library
It found FAAC but not FAAD2.
I uninstalled faad2-2.7 and faac-1.28, then installed the compiled faad2-2.8.8 and faac-1.30.
dream now recognizes both FAAD2 and FAAC without recompiling.
It looks like I need to find a way to install that works!
----Steve
Ok. So I may have partially steered you wrong. I'm using faad2-2.8.8 and faac-1.29.9.2 (both provided by Homebrew on a MBP), and faad2-2.8.8 seems to already include a libfaad_drm library built (libfaad_drm.a, libfaad_drm.dylib, libfaad_drm.2.dylib).
Considering Macs use .dylib vice .lib, is that similar to what your distribution has as well? If so, the codec thing may be a moot point, and we can move on to how the output is created/used: malloc/memory issue? device permissions issue? Trying to think what else it could be.
With the compiled version, I found these files:
Installed Program: faad (/usr/local/bin/faad)
Installed Library: libfaad.so and libfaad_drm.so
/usr/local/lib/libfaad.so.2.0.0
/usr/local/lib/libfaad.a
/usr/local/lib/libfaad.la
/usr/local/lib/libfaad_drm.so.2.0.0
/usr/local/lib/libfaad_drm.a
/usr/local/lib/libfaad_drm.la
I don't know if there was a copy of faad.h or neaacdec.h anywhere at the time it was crashing.
However, I do find them now. The dates are from the time I installed the compiled faad2-2.8.8 version again. I have tried what seems like everything.
/usr/local/include/faad.h
/usr/local/include/neaacdec.h
With the packager version,
I found these files:
/usr/bin/faad /usr/include/faad.h (didn't look for neaacdec.h)
/usr/lib/aarch64-linux-gnu/libfaad_drm.so.2.0.0
/usr/lib/aarch64-linux-gnu/libfaad_drm.a
/usr/lib/aarch64-linux-gnu/libfaad.so.2.0.0
/usr/lib/aarch64-linux-gnu/libfaad.a
/usr/lib/aarch64-linux-gnu/libfaac_drm.so.0.0.0
/usr/lib/aarch64-linux-gnu/libfaac_drm.a
/usr/lib/aarch64-linux-gnu/libfaac.so.0.0.0
/usr/lib/aarch64-linux-gnu/libfaac.a
I never have found any .dylib files.
I have found that Dream is very sensitive about the audio interfaces, crashing mostly on interfaces that actually exist. See my first post.
I can go to the AM dialogue and get audio passthrough from the input provided by gqrx.
----Steve
.dylib is the MacOS (FreeBSD?) equivalent of .lib, so you wouldn't see them in any Linux distribution.
I am starting to think it's something to do with the internal buffering. I made some changes in 1352 in this branch. I had a special case with a sketchy external USB-sound card that was having buffering problems and locking up on specific capture events. You can download a snapshot from a page at that link.
Maybe see if that fixes your problem as well? You may have to re-apply the fixes from that changes.txt, since I haven't applied them to that branch yet (but I really should at some point). I really should sync my local tree, since it's been ages...
Just so you know, I also use gqrx with an Airspy HF+ Discovery and am able to pipe gqrx through a virtual cable to Dream just fine using my reworked build. Might be the best place to start.
I will try that branch when I have time, maybe tonight.
Should the Dream qmake output include:
...
Project MESSAGE: with FAAD2
Project MESSAGE: with FAAC
I didn't see that in the list when I did my installation.
What would affect this?
Dream still finds FAAD2 and FAAC when it runs.
----Steve
Those messages are ok. Just means it found appropriate libraries for FAAD2 and FAAC and is building with them in mind.
I don't think I had those in my qmake messages.
Dream does find faad and faac when it runs.
Still with compiled faad2-2.8.8 and faac-1.30
Should I use the packager version?
Here's an interesting note:
https://sourceforge.net/p/drm/discussion/codec/thread/3999cec3/
Julian Cable - 2019-01-01
Great news - the new snapshot has AAC decoding built in using the Fraunhoffer fdk-aac codec.
Among other things, the About Dream, Version 2.2.1 dialogue says:
FhG IIS Journaline Decoder Features NewsService Journaline(R) decoder technology by Fraunhofer IIS, Erlangen, Germany. For more information visit http://www.iis.fraunhofer.de/en/bf/db/pro.html
...and
Opus Interactive Audio Codec (libopus 1.3.1) http://www.opus-codec.org
Does this mean that it isn't even using the AAC codecs that were installed?
I went to your web page and clicked Download Snapshot. I got drm-code-r1352-branches-dream-mjf.zip
I compiled with
qmake CONFIG+=alsa CONFIG+=sound
make -j4
I ran the program from the install directory
$ ./dream -I pulse -O pulse
Got FAAD2 library
Got FAAC library
qmake output, no codecs mentioned:
Info: creating stash file /home/dietpi/dream/.qmake.stash
Project MESSAGE: Qt 5 release GUI mode
Project MESSAGE: building on Linux
Project MESSAGE: with opus
Project MESSAGE: with libsndfile
Project MESSAGE: with libspeexdsp
Project MESSAGE: with hamlib
Project MESSAGE: with Qwt
Project MESSAGE: with alsa
Project MESSAGE: Qt modules core gui network xml widgets svg concurrent
This time, in System Evaluation, the Input PSD and Input Spectrum graphs worked. Before, they only had a blue line at the far left.
Waterfall input Spectrum worked before
Shifted PSD worked before
Audio Spectrum is blank
SNR Spectrum works, may have before
Dream crashed several time with stack smashing detected when high SNR was reached.
I have the output to the terminal. There is a lot there.
Bottom few lines:
initplay 38400
initrec 1280
DecOpen sample rate 48000
DecOpen sample rate 48000
stack smashing detected : terminated
Aborted
Are there useful debug messages that I can enable?
Any tests to try? I don't always get a good enough signal to start decoding.
There is some talk on the web that Raspberry Pi needs to have the non floating version of the codcecs. Was that pre RPI 4?
----Steve
Lots of questions. Unfortunately I don't have many answers.
I assume you should continue using the packager versions, since it's seeing them. So I wouldn't change anything about the codecs right now.
Audio spectrum would be blank until it produces any audio.
To be honest, I'm at a loss as to why it doesn't work on your system. Maybe just run dream without the -I and -O switches, then manually set the sound card input and output options in Settings. It should save them for use the next time.
Is appears that OSS is the default sound system for Dream. I have it installed.
osspd-alsa/stable,now 1.3.2-12.2 arm64 [installed]
osspd-pulseaudio/stable,now 1.3.2-12.2 arm64 [installed]
osspd/stable,now 1.3.2-12.2 arm64 [installed]
With no dream.ini, starting dream with no audio interface specified:
ALSA lib pcm_oss.c:377:(_snd_pcm_oss_open) Unknown field port
open error: Invalid argument
alsa CSoundOut::Init_HW playback, can't open oss
./dream -I default -O default
Dream runs
ALSA lib pcm_oss.c:377:(_snd_pcm_oss_open) Unknown field port
open error: Invalid argument
Signal input device has oss selected, signal output device has default.
In Pulse Audio Volume Control
There is no input device, but the output (default) is present.
Selecting pulse as the input device causes Dream to crash.
initrec 0
ALSA lib pcm_oss.c:377:(_snd_pcm_oss_open) Unknown field port
open error: Invalid argument
alsa CSoundIn::Init_HW record, can't open oss
...
QMutex: destroying locked mutex
Selecting pulse for output also crashes Dream.
./dream -I pulse -O default
Dream runs.
In Pulse Audio Volume Control
Input device is pulse and present, the output (default) is present.
Audio on Dream feed through AM works.
I should try this setup tonight.
I only have an hour or two of DRM per night, so this could take forever.
It's apparent that audio is an issue, but I do get audio output with the AM feature, so something is working.
Dream is very likely to crash with a valid audio device specified. Specifying an non existant audio device does not crash Dream.
Pulse works for input and output devices, only if they were specified on the command line. default works for audio output if specified from the command line.
I will change back to the system package AAC codecs.
----Steve
Not sure where you're located, but you could also try Kuwait in Arabic on 15110 from 0945-1325 UT. Can also try Romania on 7315 from 20-2100 (as in, right now), then 9620 from 21-22 UT.
Also getting biteXpress from Germany on 15785, which is a pleasant surprise. Hadn't heard them in ages.
Last edit: Mark J. Fine 2021-09-27
I am in Michigan, USA.
Nothing on 7315 now.
I did get Romainia RRI Galbeni TX1 on 7325 at 06:00 Z, got identification, not strong enough to decode.
Right now there is a very weak signal on 9620 21:00 Z
I am seeing 15785 so weak that I can barely make it out on the waterfall.
On biteXpress from Germany on 15785, never a good enough signal to decide, but I did get the identification briefly. It caused a Segmentation fault several times.
biteXpress from Germany on 15785, never a good enough signal to decode, but it always caused a Segmentation fault eventually, but I got brief station info.
EEP xHE-AAC Stereo
FL xHE-AAC
(14.84 kbps) no codec available + MM... (was cut off in window)
Why don't I have a codec for this, but you do?
Not sure, but xHE-ACC eventually crashes on mine after a rapid fade out/in anyway. First noticed that on R. Marti when they were doing DRM.
Again, I'm on a Mac, which is basically Free BSD, but with libraries supplemented by Homebrew, not a formal Linux release. There could be lots of differences between this and other distributions.
I'm going to try and sync up my local build directory with the branch today. Maybe there's something I did between then and now that adds the magic bullet.
Last edit: Mark J. Fine 2021-09-28
So, apparently there are significant changes between the branch and my local version. I will try to sync it using svn but I need to remember how to do that... been forever since I did it so it may take some time to do.
Just in case, here's an executable diff/patch file of all the changes between my branch (-) and local (+) builds. First thing you'll notice is the addition of fdk-aac to the linux CONFIG, which may be part of the problem you're having.
My branch works well with fdk-aac for both xHE-AAC and AAC.
Rafael
On 9/28/21 4:06 PM, Mark J. Fine wrote:
Ok, so I think I've managed to sync things up so the branch matches my local build.
@rafael2k: I agree regarding xHE AAC. This has been a terrible year for me to do anything that requires detailed focus and attention.
Also, I wouldn't say I've taken over Dream development/maintenance as much as incorporated some changes in my own branch that keep it in-line with other related parts - some that I think you even provided. Frankly, I'm not smart enough about the way DRM works, nor the architecture of this software, which has evolved for over 20 years now. 😂
Is it your branch that you gave me the link to previously?
https://sourceforge.net/p/drm/code/HEAD/tree/branches/dream-mjf/
Are the Hamlib and Qwt patches in changes.txt incorporated now?
If all of these work including the branch of Rafael Diniz, will they be merged with the main branch?
----Steve
Steven:
Yes. The link to the branch should be the same, and it includes all of the updates for Qwt and Hamlib.
As for merging: I'm pretty sure Rafael and I only have access to our individual branches. It would be up to a project admin to review and merge, if deemed appropriate. Unfortunately, I'm pretty sure that the rudimentary way I was able to sync my changes (committing file by file, instead of issue by issue) didn't make it very easy for a reviewer to do their job.