No-longer-functional audio with Mac OS X 10.8/MacPorts dependencies

[Kevin Reid]

I've been successfully using Gqrx on Mac OS 10.7.something with my RTL device for a few months. However, I just upgraded to Mac OS X 10.8.3 and reinstalled gnuradio, gr-osmosdr, etc. via MacPorts, and rebuilt Gqrx (clean build, revision 1673204ea925d93348781a53a6ab80a9382494b7 a.k.a. v2.1-git-274-g1673204, "git clean -fx; qmake gqrx.pro; make"), and audio no longer works.

Specifically, all of the controls work and I see stations and even the audio FFT shows something reasonable, but the audio I actually hear is a faint constant sound (the particular character of which varies on each run). Except for the very first time I ran it, where I got a bit of ordinary not-tuned-to-any-station static and then the constant sound.

• The sound does not vary with the app's gain setting but does with the OS's volume control. I've tried different audio devices with the same results.

• Good ol' multimode.py produces audio just fine.

• I was previously using Gqrx revision 4817b4d90ddcaed66d60252b59cfa796f810cc75 (the head of the "gr-audio" branch at the time), but had to move forward because it wouldn't build against MacPorts' current gnuradio. (Not that I had reason to stick to the old version.)

Any suggestions for troubleshooting?

[Alexandru Csete]

Hi Kevin,

Sorry to hear that something got broken. I believe I had similar
experience when tried gqrx with gnuradio/macports a month or two ago.
Unfortunately, I didn't have time to look into the matter and probably
wont have time before July.

I know of some suspicious code in gqrx, around line 119 in
applications/gqrx/receiver.cpp:
https://github.com/csete/gqrx/blob/master/applications/gqrx/receiver.cpp#L119

#ifndef WITH_PULSEAUDIO
if(d_demod != RX_DEMOD_OFF)
set_output_device("");
#endif

Maybe you can remove it and try again. I don't remember where that
code comes from and why it is there. Getting old I suppose...

Alex

> --
> You received this message because you are subscribed to the Google Groups
> "Gqrx SDR" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to gqrx+uns...@googlegroups.com.
> To post to this group, send email to gq...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/gqrx/-/abRQXOt6MasJ.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Kevin Reid]

On Apr 23, 2013, at 2:22, Alexandru Csete <oz9...@gmail.com> wrote:

> I know of some suspicious code in gqrx, around line 119 in
> applications/gqrx/receiver.cpp:
> https://github.com/csete/gqrx/blob/master/applications/gqrx/receiver.cpp#L119
>
> #ifndef WITH_PULSEAUDIO
> if(d_demod != RX_DEMOD_OFF)
> set_output_device("");
> #endif
>
> Maybe you can remove it and try again. I don't remember where that
> code comes from and why it is there. Getting old I suppose...

Thanks for the suggestion.

I tried disabling that code and got no change in the behavior.

I neglected to mention this the first time, but the very faint constant sound I hear starts and stops in sync with the Start/Stop DSP command. This suggests to me that the problem is not with connecting to an audio output device but with the data being delivered to it.

--
Kevin Reid <http://switchb.org/kpreid/>

[Andras Bato]

Hello Alexandru,

I have installed gqrx under Ubuntu Linux V13.04 and it started at once with my SoftRock Ensamble RX II LF/HF(HF) receiver.

Got three problems:

1. Sound is not loud enoggh,

2. RF gain button is disabled,

3. there's no waterfall.

Can you help me?

gl de ha6nn

Andras

[Alexandru Csete]

Hi Andy,

I can't help you because that receiver hardware is not supported by
gqrx. Maybe later, but I can't say when.

Alex

[Andras Bato]

Hi Alex,

My receiver hardware is supported by gqrx.

Just visit:

http://pkgs.org/ubuntu-12.10/ubuntu-universe-amd64/quisk_3.6.2-1_amd64.deb.html

It says:

quisk deb

quisk - Software Defined Radio (SDR)

• Distribution: Ubuntu 12.10
• Repository: Ubuntu Universe amd64
• Package name: quisk
• Package version: 3.6.2-1
• Package architecture: amd64
• Package type: deb
• Binary package: quisk_3.6.2-1_amd64.deb
• Source package: quisk
• Installed size: 896 B
• Download size: 255,03 KB

Quisk uses ALSA sound drivers or PortAudio and offers these capabilities:

* Quisk can control the HiQSDR.

* As a receiver it can use the SDR-IQ by RfSpace as a sample

source. There are several decimation rates available. The QUISK

receiver will read the sample data, tune it, filter it, demodulate

it, and send the audio to the sound card for output to external

headphones or speakers.

* As a receiver it can use your soundcard as a sample source. You

supply a complex (I/Q) mixer to convert radio spectrum to a low

IF, and send that IF to the left and right inputs of the sound

card in your computer. The demodulated audio goes to the same

soundcard for output.

* Quisk can control SoftRock hardware for both receive and transmit...etc

gl de ha6nn

Andy

[Alexandru Csete]

That is quisk.

This list is for gqrx

[Andras Bato]

Sorry! :)

[Kevin Reid]

On Apr 21, 2013, at 15:34, Kevin Reid <kpr...@switchb.org> wrote:

> I've been successfully using Gqrx on Mac OS 10.7.something with my RTL device for a few months. However, I just upgraded to Mac OS X 10.8.3 and reinstalled gnuradio, gr-osmosdr, etc. via MacPorts, and rebuilt Gqrx (clean build, revision 1673204ea925d93348781a53a6ab80a9382494b7 a.k.a. v2.1-git-274-g1673204, "git clean -fx; qmake gqrx.pro; make"), and audio no longer works.

[...]

> • I was previously using Gqrx revision 4817b4d90ddcaed66d60252b59cfa796f810cc75 (the head of the "gr-audio" branch at the time), but had to move forward because it wouldn't build against MacPorts' current gnuradio. (Not that I had reason to stick to the old version.)

Just a FYI followup:

I have now git bisect'ed my way around the history, and found that the audio does not work all the way back to d0cc74afcbc7e3d00f5a2b4a29f7b2089d489327 (Thu Apr 11 08:53:07 2013; Update to new gr-osmosdr header structure.) and older versions won't compile against my gr-osmosdr, of course.

Any further troubleshooting will depend on me getting some enthusiasm for digging into C++ code to start tracing where the audio signal is lost, or backporting the header changes.

Less tedious suggestions still welcome.

[Kevin Reid]

On May 13, 2013, at 6:54, Kevin Reid <kpr...@switchb.org> wrote:
> I have now git bisect'ed my way around the history, and found that the audio does not work all the way back to d0cc74afcbc7e3d00f5a2b4a29f7b2089d489327 (Thu Apr 11 08:53:07 2013; Update to new gr-osmosdr header structure.) and older versions won't compile against my gr-osmosdr, of course.

Finished the bisect; I needed the header change and also a workaround for an incompatibility between Boost and Qt's moc.

The actual commit introducing my audio problem is:
------------------------------------------------------------------------
commit 927e84f8b22001472ff81e810b672bf886d08ff9
Author: Alexandru Csete <oz9...@gmail.com>
Date: Sat Feb 9 12:49:26 2013

Introduce some input/output pasrameter checks.

When setting device strings or sample rate, check if the new settings
asre different from the old ones and do nothing if the settings haven't
changed. The reduces the number of 'i/o device errors' since we don't
try to re-open the same device.
------------------------------------------------------------------------

By disabling QT_NO_DEBUG_OUTPUT, I find that the output device string is the empty string, so receiver::set_output_device always does nothing! If I add "false &&" to the conditional in set_output_device, then audio works normally.

------------------------------------------------------------------------
diff --git a/applications/gqrx/receiver.cpp b/applications/gqrx/recei...
index b0e6611..c7a0e6c 100644
--- a/applications/gqrx/receiver.cpp
+++ b/applications/gqrx/receiver.cpp
@@ -173,7 +173,7 @@ void receiver::set_input_device(const std::string...
/*! \brief Select new audio output device. */
void receiver::set_output_device(const std::string device)
{
- if (output_devstr.compare(device) == 0)
+ if (false && output_devstr.compare(device) == 0)
{
#ifndef QT_NO_DEBUG_OUTPUT
std::cout << "No change in output device:" << std::endl
------------------------------------------------------------------------

I see that receiver::receiver does initialize audio_snk approximately like receiver::set_output_device does, and unconditionally, so I suspect there is some deeper issue (perhaps order-of-initialization related) at work; any suggestions?

I note that Alexandru Csete previously suggested I *remove* the set_output_device(""); in receiver::start(); if I do that, while also keeping the above disabled condition, then audio doesn't work (or rather, it sounds OK until about a second and then turns into a constant buzz, which I suspect is a circular buffer nobody's writing to).

This indicates that the re-setting of the audio device is critical; as to *why* that's so, I'm not familiar enough with the system yet to say. I hope someone else can pick it up from here or provide some advice.

[Alexandru Csete]

Hi Kevin,

Thanks for following up on this. I will take a look at it and see if I
can fix this as soon as I have some time - probably in July, but it
could also be before that.

Alex

[Kevin Reid]

On May 18, 2013, at 18:05, Kevin Reid <kpr...@switchb.org> wrote:

> This indicates that the re-setting of the audio device is critical; as to *why* that's so, I'm not familiar enough with the system yet to say.

Another observation:

I'm experimenting with writing a SDR app from scratch (or at least starting from just gnuradio) in Python, and I just met a different cause of this problem myself: if I do this to a top block with an audio_sink:
.start()
.stop()
.wait()
.start()
then the audio stops working in similar fashion. Discarding and recreating the audio sink between wait() and start() avoids the problem.

This doesn't explain why Gqrx exhibits the problem *without* having restarted the flow graph — at least, I looked over the code and it doesn't seem like it does if you only launch it and click “Start DSP” once.

[Alexandru Csete]

Hi Kevin,

Thanks for the update.
I suspect the osx audio sink code hasn't been updated for many years.
I've been told that deleting and recreating gnuradio blocks is a bad
thing to do - they don't really get deleted until the program exits
and in case of hardware interface blocks you may end up in a "device
or resource busy" situation the second time you try to open it.

Alex

[Alexandru Csete]

I have just pushed a change which may fix this problem. The hint came
from Elias (who makes the mac binary) suggesting that we need to reset
the audio otherwise it will make noise. This is basically what you
observed in python. Can anybody test to see if it fixes the problem?

Alex

[Kevin Reid]

On Jul 4, 2013, at 8:18, Alexandru Csete <oz9...@gmail.com> wrote:

> I have just pushed a change which may fix this problem. The hint came
> from Elias (who makes the mac binary) suggesting that we need to reset
> the audio otherwise it will make noise. This is basically what you
> observed in python. Can anybody test to see if it fixes the problem?

I just tested:

commit fd40e97e8b86f126c05315b6c9c02e8efb1212d5
Author: Alexandru Csete <oz9...@gmail.com>
Date: Thu Jul 4 08:11:22 2013

Always reset audio output device on Mac OS X.

This hopefully fixes issue #66 and issue #78.

and it does NOT fix the problem. However, the reason it does not fix the problem is that there is no Q_WS_MAC macro, so the conditional is not having the effect you intended. (I also ran gcc -E -dM and did not find any defined macro at all similar, so I don't know what the condition should be.) If I arrange so the return is in fact disabled, then it does eliminate the problem.

I see gnuradio itself uses a Q_WS_MAC macro, but I don't see where it becomes defined.


--------------------------------------------------------------------


However, this is arguably not the right fix. For example, the same problem will occur if I change the state of the “Swap I/Q” option. This is because the underlying failure occurs (as I have since found out myself) not just on stop() and start(), but also any time the flow graph is reconfigured (which in this example occurs inside of the iq_swap_cc). Which, now that I look at gnuradio source, is not surprising since unlock() actually restarts internally.

So, to do the entire job, gqrx would need a hook which rebuilds the audio sink after (rather, just before the unlock() of) any reconfiguration.


--------------------------------------------------------------------


Of course, the real “right fix” is to fix gnuradio's OS X audio blocks. I suppose I should look into that. In fact, this code (3.7, but 3.6 is basically the same) looks suspicious:

bool
osx_sink::start()
{
if(!IsRunning()) {
OSStatus err = AudioOutputUnitStart(d_OutputAU);
CheckErrorAndThrow(err, "AudioOutputUnitStart",
"audio_osx_sink::start");
}

return (true);
}

bool
osx_sink::stop()
{
if(IsRunning ()) {
OSStatus err = AudioOutputUnitStop(d_OutputAU);
CheckErrorAndThrow(err, "AudioOutputUnitStop",
"audio_osx_sink::stop");

for(UInt32 n = 0; n < d_n_channels; n++) {
d_buffers[n]->abort();
}
}

return (true);
}

I don't know how these components are supposed to be used, but the circular_buffer abort() sets a flag d_doAbort which isn't cleared except by reset(), so maybe start() should include a matching reset(). I don't know whether that would be sufficient.

I'll try to find out.

[Alexandru Csete]

On Thu, Jul 4, 2013 at 6:20 PM, Kevin Reid <kpr...@switchb.org> wrote:

On Jul 4, 2013, at 8:18, Alexandru Csete <oz9...@gmail.com> wrote:

> I have just pushed a change which may fix this problem. The hint came
> from Elias (who makes the mac binary) suggesting that we need to reset
> the audio otherwise it will make noise. This is basically what you
> observed in python. Can anybody test to see if it fixes the problem?

I just tested:

commit fd40e97e8b86f126c05315b6c9c02e8efb1212d5
Author: Alexandru Csete <oz9...@gmail.com>
Date:   Thu Jul 4 08:11:22 2013

    Always reset audio output device on Mac OS X.

    This hopefully fixes issue #66 and issue #78.

and it does NOT fix the problem. However, the reason it does not fix the problem is that there is no Q_WS_MAC macro, so the conditional is not having the effect you intended. (I also ran gcc -E -dM and did not find any defined macro at all similar, so I don't know what the condition should be.) If I arrange so the return is in fact disabled, then it does eliminate the problem.

I see gnuradio itself uses a Q_WS_MAC macro, but I don't see where it becomes defined.

Thanks for the quick feedback. Q_WS_MAC should be defined in Qt:
http://qt-project.org/doc/qt-4.8/qtglobal.html
I believe the WS stands for Window System. I see there is also a Q_OS_MAC - maybe that is defined and could be used instead? Or maybe my use of #ifndef is incorrect because there are other places (e.g. dockuirxopt.cpp) where it seems to work.

 

However, this is arguably not the right fix. For example, the same problem will occur if I change the state of the “Swap I/Q” option. This is because the underlying failure occurs (as I have since found out myself) not just on stop() and start(), but also any time the flow graph is reconfigured (which in this example occurs inside of the iq_swap_cc). Which, now that I look at gnuradio source, is not surprising since unlock() actually restarts internally.

So, to do the entire job, gqrx would need a hook which rebuilds the audio sink after (rather, just before the unlock() of) any reconfiguration.

I've been told that doing this .reset() thing on boost shared pointers is wrong and may not have the effect one hopes for.
 

Of course, the real “right fix” is to fix gnuradio's OS X audio blocks. I suppose I should look into that. In fact, this code (3.7, but 3.6 is basically the same) looks suspicious:

    bool
    osx_sink::start()
    {
      if(!IsRunning()) {
        OSStatus err = AudioOutputUnitStart(d_OutputAU);
        CheckErrorAndThrow(err, "AudioOutputUnitStart",
                           "audio_osx_sink::start");
      }

      return (true);
    }

    bool
    osx_sink::stop()
    {
      if(IsRunning ()) {
        OSStatus err = AudioOutputUnitStop(d_OutputAU);
        CheckErrorAndThrow(err, "AudioOutputUnitStop",
                           "audio_osx_sink::stop");

        for(UInt32 n = 0; n < d_n_channels; n++) {
          d_buffers[n]->abort();
        }
      }

      return (true);
    }

I don't know how these components are supposed to be used, but the circular_buffer abort() sets a flag d_doAbort which isn't cleared except by reset(), so maybe start() should include a matching reset(). I don't know whether that would be sufficient.

I'll try to find out.

I don't know if there is any maintainer of the OS audio sink and it'd be great if you could look into it :)

Alex

[Kevin Reid]

On Jul 4, 2013, at 11:25, Alexandru Csete <oz9...@gmail.com> wrote:

> Thanks for the quick feedback. Q_WS_MAC should be defined in Qt:
> http://qt-project.org/doc/qt-4.8/qtglobal.html
> I believe the WS stands for Window System. I see there is also a Q_OS_MAC - maybe that is defined and could be used instead? Or maybe my use of #ifndef is incorrect because there are other places (e.g. dockuirxopt.cpp) where it seems to work.

According to gcc -E -dM (disclaimer: the build chose clang++ as compiler rather than gcc, but it doesn't document a comparable option), these are the only macros starting with Q defined:

#define QT_GUI_LIB 1
#define QUAD_MAX LLONG_MAX
#define QUAD_MIN LLONG_MIN
#define QT_CORE_LIB 1
#define QT_SHARED 1
#define QT_SVG_LIB 1
#define QT_NO_DEBUG 1
#define QT_NO_DEBUG_OUTPUT 1

On the other hand, if I do the same thing to qtgui/dockrxopt.cpp, then Q_WS_MAC *is* defined. And I now observe that no Qt header file is included by receiver.cpp, so I think that explains why it isn't defined in receiver.cpp.

Perhaps the condition in receiver.cpp should depend on some sort of test for whether the audio sink is in fact an audio_osx_sink?

>> So, to do the entire job, gqrx would need a hook which rebuilds the audio sink after (rather, just before the unlock() of) any reconfiguration.
>
> I've been told that doing this .reset() thing on boost shared pointers is
> wrong and may not have the effect one hopes for.

Are you replying to my below comments about the audio sink? I didn't mention reset() in regard to the above fix in gqrx. gqrx wouldn't be doing anything with gnuradio it isn't _already doing_ -- just at different times.

If you meant reset() in regard to the audio sink code below, I am not talking about the reset() method of any shared pointer, but of the circular buffer object. I am not really familiar with C++ but if I understand it right, I mean d_buffers[n]->reset(), not d_buffers[n].reset().

>> Of course, the real “right fix” is to fix gnuradio's OS X audio blocks. I suppose I should look into that. In fact, this code (3.7, but 3.6 is basically the same) looks suspicious:
>>
>> bool
>> osx_sink::start()
>> {
>> if(!IsRunning()) {
>> OSStatus err = AudioOutputUnitStart(d_OutputAU);
>> CheckErrorAndThrow(err, "AudioOutputUnitStart",
>> "audio_osx_sink::start");
>> }
>>
>> return (true);
>> }
>>
>> bool
>> osx_sink::stop()
>> {
>> if(IsRunning ()) {
>> OSStatus err = AudioOutputUnitStop(d_OutputAU);
>> CheckErrorAndThrow(err, "AudioOutputUnitStop",
>> "audio_osx_sink::stop");
>>
>> for(UInt32 n = 0; n < d_n_channels; n++) {
>> d_buffers[n]->abort();
>> }
>> }
>>
>> return (true);
>> }
>>
>> I don't know how these components are supposed to be used, but the circular_buffer abort() sets a flag d_doAbort which isn't cleared except by reset(), so maybe start() should include a matching reset(). I don't know whether that would be sufficient.

[Alexandru Csete]

On Thu, Jul 4, 2013 at 8:50 PM, Kevin Reid <kpr...@switchb.org> wrote:

On Jul 4, 2013, at 11:25, Alexandru Csete <oz9...@gmail.com> wrote:

> Thanks for the quick feedback. Q_WS_MAC should be defined in Qt:
> http://qt-project.org/doc/qt-4.8/qtglobal.html
> I believe the WS stands for Window System. I see there is also a Q_OS_MAC - maybe that is defined and could be used instead? Or maybe my use of #ifndef is incorrect because there are other places (e.g. dockuirxopt.cpp) where it seems to work.

According to gcc -E -dM (disclaimer: the build chose clang++ as compiler rather than gcc, but it doesn't document a comparable option), these are the only macros starting with Q defined:

#define QT_GUI_LIB 1
#define QUAD_MAX LLONG_MAX
#define QUAD_MIN LLONG_MIN
#define QT_CORE_LIB 1
#define QT_SHARED 1
#define QT_SVG_LIB 1
#define QT_NO_DEBUG 1
#define QT_NO_DEBUG_OUTPUT 1

On the other hand, if I do the same thing to qtgui/dockrxopt.cpp, then Q_WS_MAC *is* defined. And I now observe that no Qt header file is included by receiver.cpp, so I think that explains why it isn't defined in receiver.cpp.

Ah, of course! I have pushed a fix that defines such a flag outside of Qt scope.
 

Perhaps the condition in receiver.cpp should depend on some sort of test for whether the audio sink is in fact an audio_osx_sink?

Yes, that would be great, but no such API call exists.
 

>> So, to do the entire job, gqrx would need a hook which rebuilds the audio sink after (rather, just before the unlock() of) any reconfiguration.
>
> I've been told that doing this .reset() thing on boost shared pointers is
> wrong and may not have the effect one hopes for.

Are you replying to my below comments about the audio sink? I didn't mention reset() in regard to the above fix in gqrx. gqrx wouldn't be doing anything with gnuradio it isn't _already doing_ -- just at different times.

I was referring to audio_snk.reset() in the receiver::set_output_device() function. I do the reset() in the hope that it will destroy the object and then I create a new object; however, there is no guarantee that the object is destroyed at that time. In fact, we used to have problem with ALSA audio on linux giving "device or resource busy" until gr-audio has been fixed in 3.6.5.1

The correct way to do this would be to just pass on the new device name to the audio subsystem, but I don't think that is fully supported at the moment.

Alex