grGPS Preliminary Schematic

On Friday 07 April 2006 11:35, Eric B. wrote:

gr-audio-oss-0.8.1.tar.gz that excludes this file. I believe that package
on.
Building that stuff would then force swig to be run, causing the
potential swig version inconsistency.

Not quite sure what you mean. Currently I have to regenerate this file
with
swig in order to avoid the segfault.

The log below shows the part that does go wrong. Note that swig wasn’t
executed in order to regenerate audio_oss.cc

--------------------------------------------------------------------8<---------------------------------------------------------
gmake[3]: Entering directory
/usr/pkgsrc/ham/gnuradio-audio-oss/work/gr-audio-oss-0.8/src' if /bin/sh ../libtool --tag=CXX --mode=compile c++ -DHAVE_CONFIG_H -I. -I. -I.. -pthread -I/usr/pkg/include/gnuradio -I/usr/pkg/include/python2.4 -I/usr/include -I/usr/pkg/include -I/usr/pkg/include/cppunit -I/usr/pkg/include/python2.4 -O2 -I/usr/include -I/usr/pkg/include -I/usr/pkg/include/cppunit -I/usr/pkg/include/python2.4 -Wall -Woverloaded-virtual -pthread -MT audio_oss.lo -MD -MP -MF ".deps/audio_oss.Tpo" -c -o audio_oss.lo audio_oss.cc; \ then mv -f ".deps/audio_oss.Tpo" ".deps/audio_oss.Plo"; else rm -f ".deps/audio_oss.Tpo"; exit 1; fi mkdir .libs c++ -DHAVE_CONFIG_H -I. -I.. -pthread -I/usr/pkgsrc/ham/gnuradio-audio-oss/work/.buildlink/include/gnuradio -I/usr/pkgsrc/ham/gnuradio-audio-oss/work/.buildlink/include/python2.4 -I/usr/pkgsrc/ham/gnuradio-audio-oss/work/.buildlink/include -I/usr/pkgsrc/ham/gnuradio-audio-oss/work/.buildlink/include/cppunit -O2 -Wall -Woverloaded-virtual -pthread -MT audio_oss.lo -MD -MP -MF .deps/audio_oss.Tpo -c audio_oss.cc -fPIC -DPIC -o .libs/audio_oss.o audio_oss.cc:390: warning:int SWIG_TypeCompare(const char*, const
char*)’
defined but not used
audio_oss.cc:437: warning: swig_cast_info* SWIG_TypeCheckStruct(swig_type_info*, swig_type_info*)' defined but not used audio_oss.cc:453: warning:swig_type_info*
SWIG_TypeDynamicCast(swig_type_info*, void**)’ defined but not used
audio_oss.cc:684: warning: const char* SWIG_UnpackDataName(const char*, void*, unsigned int, const char*)' defined but not used audio_oss.cc:1032: warning:void SWIG_Python_SetErrorObj(PyObject*,
PyObject*)
’ defined but not used
audio_oss.cc:1051: warning: void SWIG_Python_SetConstant(PyObject*, const char*, PyObject*)' defined but not used audio_oss.cc:1059: warning:PyObject*
SWIG_Python_AppendOutput(PyObject*,
PyObject*)’ defined but not used
audio_oss.cc:1949: warning: int SWIG_Python_AcquirePtr(PyObject*, int)' defined but not used audio_oss.cc:2044: warning:int
SWIG_Python_ConvertFunctionPtr(PyObject*,
void**, swig_type_info*)’ defined but not used
audio_oss.cc:2071: warning: int SWIG_Python_ConvertPacked(PyObject*, void*, unsigned int, swig_type_info*)' defined but not used audio_oss.cc:2179: warning:PyObject*
SWIG_Python_InitShadowInstance(PyObject*)’ defined but not used
audio_oss.cc:2320: warning: swig_type_info* SWIG_Python_TypeQuery(const char*) ' defined but not used audio_oss.cc:2432: warning:void* SWIG_Python_MustGetPtr(PyObject*,
swig_type_info*, int, int)’ defined but not used
audio_oss.cc:3960: warning: int SWIG_AsVal_double(PyObject*, double*)' defined but not used audio_oss.cc:7947: warning:void SWIG_PropagateClientData()’ defined
but not
used
audio_oss.cc:8137: warning: void SWIG_Python_addvarlink(PyObject*, char*, PyObject*(*)(), int (*)(PyObject*))' defined but not used audio_oss.cc:8154: warning:PyObject* SWIG_globals()’ defined but not
used
c++ -DHAVE_CONFIG_H -I. -I… -pthread
-I/usr/pkgsrc/ham/gnuradio-audio-oss/work/.buildlink/include/gnuradio
-I/usr/pkgsrc/ham/gnuradio-audio-oss/work/.buildlink/include/python2.4
-I/usr/pkgsrc/ham/gnuradio-audio-oss/work/.buildlink/include
-I/usr/pkgsrc/ham/gnuradio-audio-oss/work/.buildlink/include/cppunit -O2
-Wall -Woverloaded-virtual -pthread -MT audio_oss.lo -MD -MP
-MF .deps/audio_oss.Tpo -c audio_oss.cc -o audio_oss.o >/dev/null 2>&1
--------------------------------------------------------------------8<---------------------------------------------------------

In contrast building from CVS
--------------------------------------------------------------------8<---------------------------------------------------------
/usr/pkg/bin/swig -c++ -fvirtual -python -modern
-I/usr/pkg/include/python2.4
-I/usr/pkg/include/gnuradio/swig -I/usr/pkg/include/gnuradio -module
audio_oss -o audio_oss.cc audio_oss.i
gmake all-am
gmake[1]: Entering directory `/usr/src/gnuradio/gr-audio-oss/src’
if /usr/pkg/bin/bash …/libtool --tag=CXX --mode=compile g++
-DHAVE_CONFIG_H
-I. -I. -I… -pthread -I/usr/pkg/include/gnuradio -I/usr/pkg/include
-I/usr/pkg/include/python2.4 -I/usr/pkg/include -I/usr/pkg/include
-Wall
-Woverloaded-virtual -pthread -MT audio_oss.lo -MD -MP -MF
“.deps/audio_oss.Tpo” -c -o audio_oss.lo audio_oss.cc;
then mv -f “.deps/audio_oss.Tpo” “.deps/audio_oss.Plo”; else rm -f
“.deps/audio_oss.Tpo”; exit 1; fi
mkdir .libs
g++ -DHAVE_CONFIG_H -I. -I. -I… -pthread -I/usr/pkg/include/gnuradio
-I/usr/pkg/include -I/usr/pkg/include/python2.4 -I/usr/pkg/include
-I/usr/pkg/include -Wall -Woverloaded-virtual -pthread -MT audio_oss.lo
-MD
-MP -MF .deps/audio_oss.Tpo -c audio_oss.cc -fPIC -DPIC -o
.libs/audio_oss.o
if /usr/pkg/bin/bash …/libtool --tag=CXX --mode=compile g++
-DHAVE_CONFIG_H
-I. -I. -I… -pthread -I/usr/pkg/include/gnuradio -I/usr/pkg/include
-I/usr/pkg/include/python2.4 -I/usr/pkg/include -I/usr/pkg/include
-Wall
-Woverloaded-virtual -pthread -MT audio_oss_sink.lo -MD -MP -MF
“.deps/audio_oss_sink.Tpo” -c -o audio_oss_sink.lo audio_oss_sink.cc;
--------------------------------------------------------------------8<---------------------------------------------------------

where swig regenerates the audio_oss.cc file

I’ll continue to investigate, but not right now.

If someone else wants to help sort this out, please dive in.

BTW, this problem isn’t new. It’s been in all the tarballs generated
over the last couple of years. I think we’re seeing it now because I
used swig 1.3.29 on the build machine. The swig generated code changed
for the better between 1.3.27 and 1.3.28.

This would make sense as the version of swig used here is 1.3.27.

I was going to commit an update of the latest gnuradio release into
pkgsrc and
will have to work around it if no solution comes from here.

BTW: I’ve since create a package for gr-audio-portaudio which I hope to
commit
soon.

cheerio Berndt

Hi Berndt,

I’ve spent some more time looking at this problem.
I think I know how to fix it “right”, but it’s going to take a while.
Just removing the output of swig causes a failure in the VPATH build
that takes place during “make distcheck”. I know how to fix it, but I
don’t have time right now. All the modules need the fix.

This Makefile.am pattern will remove the output of swig:

audio_oss.cc audio_oss.py: audio_oss.i $(NON_LOCAL_IFILES)
$(SWIG) $(SWIGCPPPYTHONARGS) -module audio_oss -o audio_oss.cc $<

Don’t distribute output of swig

dist-hook:
@for file in $(BUILT_SOURCES); do echo $(RM) $(distdir)/$$file; done
@for file in $(BUILT_SOURCES); do $(RM) $(distdir)/$$file; done

The general idea is to ensure that the output of swig is not included
in any of the tarballs, thus causing swig to run where ever the
tarballs are built. I think this will be a more robust fix than
trying to ensure that the output of swig is included in the
tarballs, because that will lead to potential failures on systems that
have a mix of tarball and CVS built modules. That’s not recommended,
but we shouldn’t aggravate the problem.

I will fix this problem (unless somebody beats me to it), but due to
other commitments, it’ll probably be the week of the 17th before I’ve
got time to work on it.

In the meantime, if you’ve got a local fix for the NetBSD package,
please implement it.

Eric

On Monday 10 April 2006 09:02, Eric B. wrote:

audio_oss.cc audio_oss.py: audio_oss.i $(NON_LOCAL_IFILES)
tarballs are built. I think this will be a more robust fix than
please implement it.

I also could try to update swig in pkgsrc to 1.3.29 if this is what the
current files are created by. I just won’t hold my breath that this
actually
will happen (I’m not the package maintainer for swig).

It may be quicker for me to implement the changes you suggested.

cheerio Berndt

On Friday 07 April 2006 12:41, Eric B. wrote:

The log below shows the part that does go wrong. Note that swig wasn’t
executed in order to regenerate audio_oss.cc

Note that the compile from the the tarball does succeed. It does
generate some warnings about “defined but unused”, but no compile time
errors.

Yes, I know.

I believe the reason you’re seeing the segfault (based on
circumstantial evidence – I don’t even know where it’s blowing up)
is that the gnuradio-core tarball does run swig (which it
shouldn’t), while the other tarballs don’t run swig. This would
result in gnuradio-core using “your version of swig” and all the other
tarballs using “my version of swig”. As long as they all use the
same version of swig, everything should be OK. Right now they’re not.

gdb trace show:

---------------------------------------------------------8<-----------------------------------------------------
Loaded symbols for /usr/libexec/ld.elf_so
#0 0xbbb574ca in type_new () from /usr/pkg/lib/libpython2.4.so.1.0
(gdb) where
#0 0xbbb574ca in type_new () from /usr/pkg/lib/libpython2.4.so.1.0
#1 0xbbb55d10 in type_call () from /usr/pkg/lib/libpython2.4.so.1.0
#2 0xbbb25c0c in PyObject_Call () from /usr/pkg/lib/libpython2.4.so.1.0
#3 0xbb493b8b in SWIG_Python_NewShadowInstance ()
from /usr/pkg/lib/python2.4/site-packages/gnuradio/_audio_oss.so
#4 0xbb493da6 in SWIG_Python_NewPointerObj ()
from /usr/pkg/lib/python2.4/site-packages/gnuradio/_audio_oss.so
#5 0xbb4950c1 in _wrap_audio_oss_sink_sptr_input_signature ()
from /usr/pkg/lib/python2.4/site-packages/gnuradio/_audio_oss.so
#6 0xbbb46672 in PyCFunction_Call () from
/usr/pkg/lib/libpython2.4.so.1.0
#7 0xbbb25c0c in PyObject_Call () from /usr/pkg/lib/libpython2.4.so.1.0
#8 0xbbb790d3 in ext_do_call () from /usr/pkg/lib/libpython2.4.so.1.0
#9 0xbbb76cbf in PyEval_EvalFrame () from
/usr/pkg/lib/libpython2.4.so.1.0
#10 0xbbb77336 in PyEval_EvalCodeEx () from
/usr/pkg/lib/libpython2.4.so.1.0
[…]
---------------------------------------------------------8<-----------------------------------------------------

ktrace provides the following trace:

---------------------------------------------------------8<-----------------------------------------------------
[…] 15405 1 python2.4 CALL open(0x812cc3c,1,0xbfbfde90)
15405 1 python2.4 NAMI “/dev/audio”
15405 1 python2.4 RET open 3
15405 1 python2.4 CALL ioctl(3,IOWR(‘A’,0x16,0x88),0xbfbfdd50)
15405 1 python2.4 GIO fd 3 wrote 136 bytes
“\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?^P\0\0\0^F\0\0\0\M^?\M^?\M^?\M^?\M^?

\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?^P\0\0\0^F\0\0\0\M^?\M^?\M^?\M^?

\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?”
15405 1 python2.4 GIO fd 3 read 136 bytes
“\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?^P\0\0\0^F\0\0\0\M^?\M^?\M^?\M^?\M^?

\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?^P\0\0\0^F\0\0\0\M^?\M^?\M^?\M^?

\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?”
15405 1 python2.4 RET ioctl 0
15405 1 python2.4 CALL ioctl(3,IOR(‘A’,0x15,0x88),0xbfbfdd50)
15405 1 python2.4 GIO fd 3 read 136 bytes
"@^
\0\0^A\0\0\0^P\0\0\0^F\0\0\0\M^?\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0
\0\0^A\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0
\0\0^A\0@^
\0\0^A\0\0\0^P
\0\0\0^F\0\0\0\0\0\0\0^A\0\0\0\0\0\0\0\a\0\0\0\0\0^A\0\0\0\0\0\0\0
\0\0\0\0\0\0\0\0\0 \0\0\0\0\0\0\0\0@^F\0\0
(\0\0\0^^\0\0\0\0\0\0\0^E
\0\0\0"
15405 1 python2.4 RET ioctl 0
15405 1 python2.4 CALL ioctl(3,IOWR(‘A’,0x16,0x88),0xbfbfdd50)
15405 1 python2.4 GIO fd 3 wrote 136 bytes
“\M^?\M^?\M^?\M^?^B\0\0\0\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?^B\0\0\0\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?”
15405 1 python2.4 GIO fd 3 read 136 bytes
“\M^?\M^?\M^?\M^?^B\0\0\0\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?^B\0\0\0\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?”
15405 1 python2.4 RET ioctl 0
15405 1 python2.4 CALL ioctl(3,IOR(‘A’,0x15,0x88),0xbfbfdd50)
15405 1 python2.4 GIO fd 3 read 136 bytes
"@^
\0\0^B\0\0\0^P\0\0\0^F\0\0\0\M^?\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0
\0\0^A\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0
\0\0^A\0@^
\0\0^B\0\0\0^P
\0\0\0^F\0\0\0\0\0\0\0^A\0\0\0\0\0\0\0\a\0\0\0\0\0^A\0\0\0\0\0\0\0
\0\0\0\0\0\0\0\0\0 \0\0\0\0\0\0\0\0@^F\0\0
(\0\0\0^^\0\0\0\0\0\0\0^E
\0\0\0"
15405 1 python2.4 RET ioctl 0
15405 1 python2.4 CALL ioctl(3,_IOWR(‘A’,0x16,0x88),0xbfbfdd50)
15405 1 python2.4 GIO fd 3 wrote 136 bytes
“\M^@\M-;\0\0\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^@\M-;\0\0\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?”
15405 1 python2.4 GIO fd 3 read 136 bytes
“\M^@\M-;\0\0\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^@\M-;\0\0\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?
\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?”
15405 1 python2.4 RET ioctl 0
15405 1 python2.4 CALL ioctl(3,_IOR(‘A’,0x15,0x88),0xbfbfdd50)
15405 1 python2.4 GIO fd 3 read 136 bytes
"\M^@\M-;\0\0^B\0\0\0^P\0\0\0^F\0\0\0\M^?\0\0\0\0\0\0\0\0\0\0\0\0\0
\0\0\0\0^A\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 \0\0^A\0\M^@\M-;
\0\0^B\0\

\0\0^P\0\0\0^F\0\0\0\0\0\0\0^A\0\0\0\0\0\0\0\a\0\0\0\0\0^A\0\0\0\0
\0\0\0\0\0\0\0\0\0\0\0\0
\0\0\0\0\0\0\0\0\M^@%\0\0^F\0\0\0^D\0\0\0\0
\0\0\0^E\0\0\0"
15405 1 python2.4 RET ioctl 0
15405 1 python2.4 PSIG SIGSEGV SIG_DFL
15405 1 python2.4 NAMI “python2.4.core”
---------------------------------------------------------8<-----------------------------------------------------

Let me be clear: when compiling the tarballs, swig should not run
[at least that was the original intention :wink: ] The fact that it is run
when building the gnuradio-core tarball is incorrect, and is what I
believe is causing the problem.

So, I think there are two solutions: ensure that either all of them run
swig, or that none of them run swig.

swig is executed with gr-audio-portaudio, gr-audio-oss,
gr-gsm-fr-vocoder,
gr-usrp but not with gnuradio-core and usrp

This would make sense as the version of swig used here is 1.3.27.
commit soon.

Good.

How does gr-audio-portaudio sound under NetBSD?
Does it work as well as gr-audio-oss?

I just finished and installed the portaudio package and run a few
applications. The sound is choppy, something that I haven’t noticed with
the
older version of portaudio support which had the *_portaudio.py
applications.
However, the test applications that come with portaudio work fine.

Will investigate it later on, it’s not important at the moment since
audio_oss
works fine.

FWIW, my impression of gr-audio-portaudio under GNU/Linux is that it’s
not ready for prime time. I’d still choose gr-audio-alsa over
portaudio. It still needs some work. Not sure if it’s in our code,
the portaudio code, or both.

Will do,

cheerio Berndt