Finally moved from Catalina (and Intel Macs) and rebuilt on a new 16" 2021 MBP (M1). There are a few differences on how things work:
MBP came with Monterrey and everything seemed ok at first using Rosetta2 to run Intel things... even if Homebrew refused to update anything anymore. Segue to...
Needed an entirely new Homebrew installation using all new unified or ARM builds of things. That's fine, but Homebrew installs everything in /opt/homebrew on ARM, not /usr/local. This presents a few problems, but it wasn't necessarily a simple pick up from /usr/local and drop into /opt/homebrew type of thing. For one thing, all of Qt and qwt moved, which massively messes up Qt Creator's kit settings and I had to wrestle with where QML went, what new compilers and mkspec to use, etc.
VB Cable has problems being choppy not only on Monterrey and is completely worthless in Ventura. This puts a crimp in piping audio from one app to another. An undesired workaround is to play GQRX audio through the built-in speakers, then us the built-in mics as input to Dream, using my external 5.1 USB sound device for Dream's output. #convoluted
Nevertheless, managed to get Dream built and it seems to work as arm64, best I can tell. The AM demodulator still worked using my noisy workaround, and can decode DRM using the sample FLAC files. No major code changes were needed, but decided it was worthwhile to add a PREFIX variable so you could somewhat easily swap between opt/homebrew and /usr/local in dream.pro. I'm sure there's a way to automate that but this was quick and easy.
Edit: There was a way so I implemented it.
Last edit: Mark J. Fine 2022-11-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Finding something else is amiss... Apparently Qt under Ventura has some strange quirks. Most notably is that QtMultimedia does not pick up the separate inputs of a multi-input audio device and let you select them individually. Even worse, it doesn't even pick up the default input on first blush, just the first input that's indexed on the device. Stranger still, if I select the already selected device from the Input menu, it appears to jump to the next input on the device.
In my case, I have an external audio device. The first input is an unconnected mic, then external (connected to the radio's audio out), an SPDIF, then a combined mic/external. Dream starts with the mic input, however, if I select "USB Sound Device" as the Input source again I'll get the external input. Very strange.
What makes this real bad is if you try this on the baseline or Ollie's branch, changing the input audio source crashes it. For some reason pIODevice gets crushed inside CReceiveData:ProcessDataInternal, causing it to change to being nullptr and no longer open when it tries to read from it on line 236 of creceivedata.cpp...
This last issue is likely a thread conflict, because it has to be non-null to get to that point. Either the read call or the looped threadwait statement likely pauses enough for the thread to catch up to where the user has attempted to change (and close) the last pIODevice. So, I'm looking how to solve that as well.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Determined from looking at some of Qt's log messages, that there most definitely is a threading issue with using the pAudioInput->start and ->stop methods. The internal timer it uses was created in a different thread, and Qt doesn't like that. So it might partially open and close, but the timer never really starts nor stops, and it keeps hitting the callback method (ProcessDataInternal) despite what's set to nullptr. As a workaround, the crashing can be averted by commenting out that parts that call pAudioInput->stop() and assign it nullptr (as well as delete pIODevice and pIODevice = nullptr), and moving the section that starts and checks pAudioInput from CReadData:SetSoundInterface to the similar spot in CReceiveData:SetSoundInterface. Starting it does nothing to pAudioInput except to re-assign its pointer to pIODevice, allowing it to read from the selected device.
This is fine as a workaround, but it creates another problem when trying to play a sound file, when pAudioInput really needs to be nullptr, so pSound can take over. For now, calling dream with -f <sound file> instead of using the menu will also work, because pAudioInput is never started. Kinda defeats the point of having a gui though.
Bottom line: Assuming the timers were created in the main thread or some thread Qt creates (haven't fully checked, but that's usually how these things work), perhaps the start and stop calling functions should be done there, and the ones in CReceiverData and CReadData be changed to call them through internal signalling. I assume pIODevice and pAudioInput would then have to be made global or added to Parameters or something to make them accessible. This would allow pAudioInput to start and stop as designed, and ultimately solves the file calling problem, though I suspect something similar may have to be done with pSound as well.
I fear I've not obsessed enough over this, have I? 😂
Edit: Oh, found that by setting QThread::msleep() to 100mS may be too long on faster machines, causing some popping and choppy audio in the AM Demodulator (and possibly the DRM mode, but haven't checked). Setting it to 10mS seems to make it work a lot smoother. Haven't fully done the math, but it really should be less than half of whatever a 48kHz-sampled stereo frame takes to fill the buffer: Roughly vecsSoundBuffer.size()/48 mSec or less? If I've done this right, assuming a 2048 buffer size, that'd be <= 42mS?
Last edit: Mark J. Fine 2022-12-03
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just had another thought... Since re-synching seems to also try to reset the device, could solving the pAudioInput problem finally solve the mystery of why rapid re-synching of xHE-AAC-encoded programs is a problem?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
May have to scratch the internal signalling idea. Created a QObject named AudioInterfaceFactory that got instantiated right after DrmReceiver in the main thread, but could find no way to connect CReceiveData to it to accept signals for creating, starting, and stopping pAudioInput. In order for that to happen, CReceiveData has to be a QObject. If you add the Q_OBJECT macro to the class, the class won't build properly. Could try to funnel it up a few layers in CRx, but I think CReceiveData creates the first pAudioInput before CRx is instantiated. So, that's a problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"Apparently Qt under Ventura has some strange quirks. Most notably is that QtMultimedia does not pick up the separate inputs of a multi-input audio device and let you select them individually. Even worse, it doesn't even pick up the default input on first blush, just the first input that's indexed on the device. Stranger still, if I select the already selected device from the Input menu, it appears to jump to the next input on the device"
Once I updated Ventura to 13.1 last week, this problem went away. Seems to correctly use the previously selected input automatically from the start now. 🤷🏻♂️
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"Apparently Qt under Ventura has some strange quirks. Most notably is that QtMultimedia does not pick up the separate inputs of a multi-input audio device and let you select them individually. Even worse, it doesn't even pick up the default input on first blush, just the first input that's indexed on the device. Stranger still, if I select the already selected device from the Input menu, it appears to jump to the next input on the device"
Once I updated Ventura to 13.1 last week, this problem went away. Seems to correctly use the previously selected input automatically from the start now. 🤷🏻♂️
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.
Had not tried the Homebrew recipe, but I have stumbled onto a replacement for VB Cable that works just fine under Ventura, called BlackHole (https://github.com/ExistentialAudio/BlackHole). Am using the 2-channel variety.
Between this and the other fixes/workarounds, now I just need Kuwait to fix their transmission and propagation to improve. I've not had a good enough signal from anywhere to decode anything. The only way I know things are working right now is by using the sample sound files.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Check that: Actually had good enough reception of KTWR this morning on 9910. However, this was a pretty easy 4/16-QAM mono signal. Kuwait is more complex (I think) using 16/64 p-stereo.
Mark,
I have been struggling to get Dream running on my MBA M2. (I also have a MacMini M1). I am not an experienced developer, but I would really like to get access to receive DRM broadcasts, and Dream seems to be the only thing around. Would it be possible for you share one of your compiles (dmg) on M1/M2 with me so that I can try it out?
Pascal AC7N
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Am skittish about providing something already compiled not knowing your exact configuration (versions of prerequisites such as qt, etc.). I'm also not the application's developer so providing this is a bit presumptive of usage and distribution rights on my part.
That said, I've included the attached - a dmg containing a compiled version of v2.3.
Again, it works for me and uses links to things in homebrew, but please understand that's no guarantee that it will work for you if those links don't exist on your machine.
Mark,
I understand. I did try launching the app after dragging it from the dmg. Unfortunately, I get a message that says the "app is damaged" and it will not open.
I am willing to try building the app myself. I have HomeBrew and Xcode. Could you point me to the up-to-date instructions for building on Mac (what you did)?
Pascal AC7N
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As I mentioned, if you don't have all the parts it needs, macOS will say it's damaged because it can't find a dependent static or dynamically linked library. It really isn't damaged, per se.
I don't have any concise up-to-date instructions on how to build it, but I did not use XCode. I used Qt Creator on the qt .pro file in the cvs. You may have homebrew, but unless you've installed qt@5, qwt-qt5, and all of the rest of the dependent formulae, and optionally, the qt-creator cask to build it in, it may not work.
Another problem that it's been so long I don't even remember all the other prerequisites it needs... Best I can tell from the qt .pro file, the homebrew dependencies that need to be installed would be: qt@5, qwt-qt5, libsndfile, libvorbis, hamlib, speex, speexdsp, fdk-aac, fftw, portaudio, pulseaudio, opus, opusfile, soapysdr, libusb... lord knows whatever else I'm leaving out.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Mark,
Appreciate your response. This is helpful. I haven't done anything with QT Creator, so not familiar. But, what you have given me is helpful. I can try installing all of the dependencies using homebrew, and try launching the dmg again. In any event, I sure wish that this software was in a more usable state for both us Macos users, as well as Windows. I'll look at this some more when I have time, and see where it leads.
Pascal AC7N
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Rarely are Qt-based apps distributed as self-contained applications. They usually require other external dynamically linked libraries. The real benefit of Qt is supposed to be a unified, cross-platform interface at the code level, but not at the compiled level. I only know of Java that can do that with compiled .jar files, and other interpretive scripting languages such as Python.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In theory you could link the binary as a static object... so no external
dependencies.
Rafael
On 7/10/23 19:15, Mark J. Fine wrote:
Rarely are Qt-based apps distributed as self-contained applications.
They usually require other external dynamically linked libraries. The
real benefit of Qt is supposed to be a unified, cross-platform interface
at the code level, but not at the compiled level. I only know of Java
that can do that with compiled .jar files, and other interpretive
scripting languages such as Python.
Mark,
More context for my situation. I had an old, old version of Dream (I think v 1.17) running on a Windows laptop. I have not seen success in running newer versions, even on Windows. However, I am now fully Mac (13" MacBook Air M2 and a Mac Mini M1). I use an Icom IC-7300 as the receiver, and tap the IF output over usb. I also have an Airplay SDR1a which I would like to use with the MBA. So, a version which runs on M1/M2 Ventura would be wonderful.
I do have HomeBrew installed and working.
Pascal AC7N
Last edit: Pascal Nelson 2023-07-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Finally moved from Catalina (and Intel Macs) and rebuilt on a new 16" 2021 MBP (M1). There are a few differences on how things work:
MBP came with Monterrey and everything seemed ok at first using Rosetta2 to run Intel things... even if Homebrew refused to update anything anymore. Segue to...
Needed an entirely new Homebrew installation using all new unified or ARM builds of things. That's fine, but Homebrew installs everything in /opt/homebrew on ARM, not /usr/local. This presents a few problems, but it wasn't necessarily a simple pick up from /usr/local and drop into /opt/homebrew type of thing. For one thing, all of Qt and qwt moved, which massively messes up Qt Creator's kit settings and I had to wrestle with where QML went, what new compilers and mkspec to use, etc.
VB Cable has problems being choppy not only on Monterrey and is completely worthless in Ventura. This puts a crimp in piping audio from one app to another. An undesired workaround is to play GQRX audio through the built-in speakers, then us the built-in mics as input to Dream, using my external 5.1 USB sound device for Dream's output. #convoluted
Nevertheless, managed to get Dream built and it seems to work as arm64, best I can tell. The AM demodulator still worked using my noisy workaround, and can decode DRM using the sample FLAC files. No major code changes were needed, but decided it was worthwhile to add a PREFIX variable so you could somewhat easily swap between opt/homebrew and /usr/local in dream.pro. I'm sure there's a way to automate that but this was quick and easy.
Edit: There was a way so I implemented it.
Last edit: Mark J. Fine 2022-11-27
Finding something else is amiss... Apparently Qt under Ventura has some strange quirks. Most notably is that QtMultimedia does not pick up the separate inputs of a multi-input audio device and let you select them individually. Even worse, it doesn't even pick up the default input on first blush, just the first input that's indexed on the device. Stranger still, if I select the already selected device from the Input menu, it appears to jump to the next input on the device.
In my case, I have an external audio device. The first input is an unconnected mic, then external (connected to the radio's audio out), an SPDIF, then a combined mic/external. Dream starts with the mic input, however, if I select "USB Sound Device" as the Input source again I'll get the external input. Very strange.
What makes this real bad is if you try this on the baseline or Ollie's branch, changing the input audio source crashes it. For some reason pIODevice gets crushed inside CReceiveData:ProcessDataInternal, causing it to change to being nullptr and no longer open when it tries to read from it on line 236 of creceivedata.cpp...
This last issue is likely a thread conflict, because it has to be non-null to get to that point. Either the read call or the looped threadwait statement likely pauses enough for the thread to catch up to where the user has attempted to change (and close) the last pIODevice. So, I'm looking how to solve that as well.
Determined from looking at some of Qt's log messages, that there most definitely is a threading issue with using the pAudioInput->start and ->stop methods. The internal timer it uses was created in a different thread, and Qt doesn't like that. So it might partially open and close, but the timer never really starts nor stops, and it keeps hitting the callback method (ProcessDataInternal) despite what's set to nullptr. As a workaround, the crashing can be averted by commenting out that parts that call pAudioInput->stop() and assign it nullptr (as well as
delete pIODeviceandpIODevice = nullptr), and moving the section that starts and checks pAudioInput from CReadData:SetSoundInterface to the similar spot in CReceiveData:SetSoundInterface. Starting it does nothing to pAudioInput except to re-assign its pointer to pIODevice, allowing it to read from the selected device.This is fine as a workaround, but it creates another problem when trying to play a sound file, when pAudioInput really needs to be nullptr, so pSound can take over. For now, calling dream with
-f <sound file>instead of using the menu will also work, because pAudioInput is never started. Kinda defeats the point of having a gui though.Bottom line: Assuming the timers were created in the main thread or some thread Qt creates (haven't fully checked, but that's usually how these things work), perhaps the start and stop calling functions should be done there, and the ones in CReceiverData and CReadData be changed to call them through internal signalling. I assume pIODevice and pAudioInput would then have to be made global or added to Parameters or something to make them accessible. This would allow pAudioInput to start and stop as designed, and ultimately solves the file calling problem, though I suspect something similar may have to be done with pSound as well.
I fear I've not obsessed enough over this, have I? 😂
Edit: Oh, found that by setting QThread::msleep() to 100mS may be too long on faster machines, causing some popping and choppy audio in the AM Demodulator (and possibly the DRM mode, but haven't checked). Setting it to 10mS seems to make it work a lot smoother. Haven't fully done the math, but it really should be less than half of whatever a 48kHz-sampled stereo frame takes to fill the buffer: Roughly vecsSoundBuffer.size()/48 mSec or less? If I've done this right, assuming a 2048 buffer size, that'd be <= 42mS?
Last edit: Mark J. Fine 2022-12-03
Adding that second line and setting Qthread::msleep() to mwait seems to work.
Just had another thought... Since re-synching seems to also try to reset the device, could solving the pAudioInput problem finally solve the mystery of why rapid re-synching of xHE-AAC-encoded programs is a problem?
May have to scratch the internal signalling idea. Created a QObject named AudioInterfaceFactory that got instantiated right after DrmReceiver in the main thread, but could find no way to connect CReceiveData to it to accept signals for creating, starting, and stopping pAudioInput. In order for that to happen, CReceiveData has to be a QObject. If you add the Q_OBJECT macro to the class, the class won't build properly. Could try to funnel it up a few layers in CRx, but I think CReceiveData creates the first pAudioInput before CRx is instantiated. So, that's a problem.
"Apparently Qt under Ventura has some strange quirks. Most notably is that QtMultimedia does not pick up the separate inputs of a multi-input audio device and let you select them individually. Even worse, it doesn't even pick up the default input on first blush, just the first input that's indexed on the device. Stranger still, if I select the already selected device from the Input menu, it appears to jump to the next input on the device"
Once I updated Ventura to 13.1 last week, this problem went away. Seems to correctly use the previously selected input automatically from the start now. 🤷🏻♂️
My Mac is a company one and our latest supported OS is Monterey.
Have you tried the homebrew recipe? – its old but could be updated.
https://github.com/jcable/homebrew-dream
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, 18 December 2022 at 01:32
To: Julian Cable julian.cable@bbc.co.uk
Subject: [drm:discussion] Re: macos Ventura and other adventures building on M1 Macs
"Apparently Qt under Ventura has some strange quirks. Most notably is that QtMultimedia does not pick up the separate inputs of a multi-input audio device and let you select them individually. Even worse, it doesn't even pick up the default input on first blush, just the first input that's indexed on the device. Stranger still, if I select the already selected device from the Input menu, it appears to jump to the next input on the device"
Once I updated Ventura to 13.1 last week, this problem went away. Seems to correctly use the previously selected input automatically from the start now. 🤷🏻♂️
macos Ventura and other adventures building on M1 Macshttps://sourceforge.net/p/drm/discussion/compiling/thread/83797a684c/?limit=25#ea8c/2ec3/020d
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.
Had not tried the Homebrew recipe, but I have stumbled onto a replacement for VB Cable that works just fine under Ventura, called BlackHole (https://github.com/ExistentialAudio/BlackHole). Am using the 2-channel variety.
Between this and the other fixes/workarounds, now I just need Kuwait to fix their transmission and propagation to improve. I've not had a good enough signal from anywhere to decode anything. The only way I know things are working right now is by using the sample sound files.
Check that: Actually had good enough reception of KTWR this morning on 9910. However, this was a pretty easy 4/16-QAM mono signal. Kuwait is more complex (I think) using 16/64 p-stereo.
Mark,
I have been struggling to get Dream running on my MBA M2. (I also have a MacMini M1). I am not an experienced developer, but I would really like to get access to receive DRM broadcasts, and Dream seems to be the only thing around. Would it be possible for you share one of your compiles (dmg) on M1/M2 with me so that I can try it out?
Pascal AC7N
Am skittish about providing something already compiled not knowing your exact configuration (versions of prerequisites such as qt, etc.). I'm also not the application's developer so providing this is a bit presumptive of usage and distribution rights on my part.
That said, I've included the attached - a dmg containing a compiled version of v2.3.
Again, it works for me and uses links to things in homebrew, but please understand that's no guarantee that it will work for you if those links don't exist on your machine.
Mark,
I understand. I did try launching the app after dragging it from the dmg. Unfortunately, I get a message that says the "app is damaged" and it will not open.
I am willing to try building the app myself. I have HomeBrew and Xcode. Could you point me to the up-to-date instructions for building on Mac (what you did)?
Pascal AC7N
As I mentioned, if you don't have all the parts it needs, macOS will say it's damaged because it can't find a dependent static or dynamically linked library. It really isn't damaged, per se.
I don't have any concise up-to-date instructions on how to build it, but I did not use XCode. I used Qt Creator on the qt .pro file in the cvs. You may have homebrew, but unless you've installed qt@5, qwt-qt5, and all of the rest of the dependent formulae, and optionally, the qt-creator cask to build it in, it may not work.
Another problem that it's been so long I don't even remember all the other prerequisites it needs... Best I can tell from the qt .pro file, the homebrew dependencies that need to be installed would be: qt@5, qwt-qt5, libsndfile, libvorbis, hamlib, speex, speexdsp, fdk-aac, fftw, portaudio, pulseaudio, opus, opusfile, soapysdr, libusb... lord knows whatever else I'm leaving out.
Mark,
Appreciate your response. This is helpful. I haven't done anything with QT Creator, so not familiar. But, what you have given me is helpful. I can try installing all of the dependencies using homebrew, and try launching the dmg again. In any event, I sure wish that this software was in a more usable state for both us Macos users, as well as Windows. I'll look at this some more when I have time, and see where it leads.
Pascal AC7N
Rarely are Qt-based apps distributed as self-contained applications. They usually require other external dynamically linked libraries. The real benefit of Qt is supposed to be a unified, cross-platform interface at the code level, but not at the compiled level. I only know of Java that can do that with compiled .jar files, and other interpretive scripting languages such as Python.
In theory you could link the binary as a static object... so no external
dependencies.
On 7/10/23 19:15, Mark J. Fine wrote:
But then how else would we know it needed to be rebuilt? 😂
Seriously tho, next time I'm in Qt Composer I'll look into how to do that.
Mark,
More context for my situation. I had an old, old version of Dream (I think v 1.17) running on a Windows laptop. I have not seen success in running newer versions, even on Windows. However, I am now fully Mac (13" MacBook Air M2 and a Mac Mini M1). I use an Icom IC-7300 as the receiver, and tap the IF output over usb. I also have an Airplay SDR1a which I would like to use with the MBA. So, a version which runs on M1/M2 Ventura would be wonderful.
I do have HomeBrew installed and working.
Pascal AC7N
Last edit: Pascal Nelson 2023-07-10