Sorry to drag up an ancient thread. I was wondering what specific modifications were needed for the general_work function of op25_decoder_ff.cc?
Does only returning synthesized frames work or does IMBE expect for some empty results to be inserted where there is no data to smooth things out? I am trying something similar using DSD and the WAV files I record with only synthesized data do not sound as good as audio played back with empty frames returned when no data is available.
Thanks for any tips you have!
Luke
--- In op25-dev(a)yahoogroups.com, "Balint" <balint256@...> wrote:
>
> Dear all,
>
> I've uploaded to the Files section of the board a new 'audio_p25_rx.py',
> which is the original file modified to output IMBE audio, and read/write
> WAV/float data files (since I don't have a USRP and use a discriminator
> tap).
>
> Some notes:
>
> # wx must be set to 'nongl' mode (widgets are the older non-OpenGL type)
>
> # Make sure your ~/.gnuradio/config.conf has a '[wxgui]' section, which
> contains the line 'style=nongl'
>
> #
>
> # Voice output requires the environment variable 'IMBE' set to 'soft', AND
> modification to op25_decoder_ff.cc to prevent
>
> # excessive zero values being output (which chops up the real output
> stream and produces too much silence) - this can
>
> # be done by only producing 'general_work' output values when actual voice
> data is synthesised (i.e. return the number
>
> # of synthesised samples produced and don't pad the output buffer with
> silence)
>
> #
>
> # If you want to capture using Wireshark, don't forget to run this as root!
>
> # Use the '-w' wait option, then start Wireshark and begin capturing, then
> return to your terminal and hit any key.
>
>
>
> In addition, I've found that software_imbe_decoder dies sporadically at
> 'decoder/src/lib/software_imbe_decoder.cc:1022'. I believe this is because
> the class member variable 'OldL' is left un-initialised, and used as such on
> line 1018. Adding 'OldL = 0;' to the class constructor (line 756) appears to
> fix the problem (and causes the 'OldL == 0' check on line 1005 to kick in).
>
>
>
> Please let me know if you try the new Python code and have any problems.
>
> Balint
>
i tried building with './configure --enable-debug'
got the following errors:
bch.cc: In function 'int bchDec(bit_vector&)':
bch.cc:33:8: warning: variable 'root' set but not used [-Wunused-but-set-variable]
bch.cc: At global scope:
bch.cc:170:29: error: redefinition of 'const int bchGFexp [64]'
bch.cc:8:18: error: 'const int bchGFexp [64]' previously defined here
bch.cc:177:29: error: redefinition of 'const int bchGFlog [64]'
bch.cc:15:18: error: 'const int bchGFlog [64]' previously defined here
bch.cc:184:25: error: redefinition of 'const int bchG [48]'
bch.cc:22:18: error: 'const int bchG [48]' previously defined here
bch.cc: In function 'int bchDec(bit_vector&)':
bch.cc:190:5: error: redefinition of 'int bchDec(bit_vector&)'
bch.cc:28:5: error: 'int bchDec(bit_vector&)' previously defined here
bch.cc: At global scope:
bch.cc:332:29: error: redefinition of 'const int bchGFexp [64]'
bch.cc:8:18: error: 'const int bchGFexp [64]' previously defined here
bch.cc:339:29: error: redefinition of 'const int bchGFlog [64]'
bch.cc:15:18: error: 'const int bchGFlog [64]' previously defined here
bch.cc:346:25: error: redefinition of 'const int bchG [48]'
bch.cc:22:18: error: 'const int bchG [48]' previously defined here
bch.cc: In function 'int bchDec(bit_vector&)':
bch.cc:352:5: error: redefinition of 'int bchDec(bit_vector&)'
bch.cc:28:5: error: 'int bchDec(bit_vector&)' previously defined here
make[4]: *** [bch.lo] Error 1
make[4]: Leaving directory `/home/matt/op25/blocks/src/lib'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/home/matt/op25/blocks/src/lib'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/matt/op25/blocks/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/matt/op25/blocks'
make: *** [all] Error 2
indeed on inspection of the bch.h code i noticed some things. straightaway i saw that the code was not surrounded with the standard:
#ifndef INCLUDED_BCH_H
#define INCLUDED_BCH_H
#endif
so i added this and the make error is gone. i am confused as to why the header file is so spartan? no declarations?
Thanks!
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Date:2013-08-14
For a number of reasons[0], I've recently changed my email provider
and set up a new OpenPGP key. As a result I shall be immediately
transitioning away from my ten-year old PGP key.
The old key will be revoked very soon, and so I would like all future
correspondence to use the new one. I would also like this new key to
be re-integrated into the web of trust. This message is signed by
both keys to certify the transition.
The old key was:
pub 1024D/AE445B2E 2004-10-25
Key fingerprint = E27B 3AF7 C367 74C2 FFF0 40B7 5BB6 809B AE44 5B2E
and the new key is:
pub 4096R/0E7A0087 2013-08-14
Key fingerprint = AB4C DD88 559B B3AC DF63 DC76 AE2F F214 0E7A 0087
To fetch the full key from a public key server, you can simply do:
gpg --keyserver keys.riseup.net --recv-key 0E7A0087
If you already know my old key, you can now verify that the new key is
signed by the old one:
gpg --check-sigs 0E7A0087
If you don't already know my old key, or you just want to be extra
sure, you can check the fingerprint against the one above:
gpg --fingerprint 0E7A0087
If you are satisfied that you've got the right key, and the UIDs match
what you expect, I'd appreciate it if you would sign my key. You can
do that by issuing the following command:
**
NOTE: if you have previously signed my key but did a local-only
signature (lsign), you will not want to issue the following, instead
you will want to use --lsign-key, and not send the signatures to the
keyserver
**
gpg --sign-key 0E7A0087
I'd like to receive your signatures on my key. You can either send me
an e-mail with the new signatures (if you have a functional MTA on
your system):
gpg --export 0E7A0087 | gpg --encrypt -r 0E7A0087 --armor | mail -s
'OpenPGP Signatures' <smg(a)hush.com>
Additionally, I highly recommend that you implement a mechanism to keep
your key
material up-to-date so that you obtain the latest revocations, and other
updates
in a timely manner.
I also highly recommend checking out the excellent Riseup GPG best
practices doc, from which I stole most of the text for this transition
message ;-)
https://we.riseup.net/riseuplabs+paow/openpgp-best-practices
Please let me know if you have any questions, or problems, and sorry
for the inconvenience.
Steve Glass
0. https://www.debian-administration.org/users/dkg/weblog/48
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iEYEARECAAYFAlILarcACgkQW7aAm65EWy7Y3ACgu55BvaS59A3l41uDsXkrIUMi
a7AAmwTlctyIdAWDj7vXH9InucqIqGlMiQIcBAEBAgAGBQJSC2q3AAoJEK4v8hQO
egCHpJoQAKLyqNRvosqXiiiV4HvxeiiaYlzfkv6CejfynBD5vO4RR+nzim002T7I
ezCmPObO+6PtA0go3qkYn94YIKxqn1RK+ctMmWAF5utAQ0V6bEGMseIwvdzuWt4x
aoaHxdDng1ZaQJO9xS6U/SCm34vg0dQlCW+4sSiMg/GsQ2+wv71wThh81T37DuBX
bDGz53ZMA/wz/W52YJkSaEn+k+R/Js1FSFpNuCvn2NT2wZiWr05H2KKMCUgHitbi
cWA8uFD4Z4EshWJHHlRX3hdB8HygQ8N1rVb83GZjZxMGEUEfVC88ZUSt6al3ACfN
Ix9uM3xbKJ7thrl0NwrvQG/Z+ecmUyjENBeXQBwne86TzVx3E9mgoDdER7pf+zpe
rqXvMSfa+ONSghHkm9u5UCli5/kduG/0gW3eeuqCtXq08c0zJe0NzGsWUSYVNZmI
oeq1erVNpo7zzo7XHGPA8Yq3nfgFPV6A/3ivfmema/J17ngWMtym5CGy8EpJelRv
J4QNRBUGVRKBgrlX+3AvDXvtQznE/NZqE1ugbzGrdimZsxR5d5FcBJU+1+jgZ/OJ
ur//OBHPfDvF15RtiYOCi66IPC5AUrOK0gcw+x/9VHkd6olU7dJDXxx5N58/VNnm
weB+JNY3doQuch4lQVqQ5r484KzfoUS2r7ZC/o/xo2aA6kvanwpZ
=OoMf
-----END PGP SIGNATURE-----
hey,
i made some code to show information from the data units; some in the
c++ (ldu1.h, ldu1.cc, etc) and some in the python (traffic panel). now
when i leave it running for a somewhat extending period of time op25
dies with what i think is some sort of memory error:
*** glibc detected *** /usr/bin/python: free(): invalid pointer:
0xb7698434 ***
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(+0x75ee2)[0xb7567ee2]
/usr/lib/i386-linux-gnu/libstdc++.so.6(_ZdlPv+0x1f)[0xb696eadf]
/usr/lib/i386-linux-gnu/libstdc++.so.6(_ZNSs4_Rep10_M_destroyERKSaIcE+0x1b)[0xb69d67bb]
/usr/local/lib/python2.7/dist-packages/gnuradio/_op25.so(_ZN19snapshot_du_handler6handleEN5boost10shared_ptrI9data_unitEE+0x236)[0xb2ce6de6]
/usr/local/lib/python2.7/dist-packages/gnuradio/_op25.so(_ZN17data_unit_handler6handleEN5boost10shared_ptrI9data_unitEE+0x54)[0xb2ce5c74]
/usr/local/lib/python2.7/dist-packages/gnuradio/_op25.so(_ZN16voice_du_handler6handleEN5boost10shared_ptrI9data_unitEE+0x66)[0xb2ce8116]
/usr/local/lib/python2.7/dist-packages/gnuradio/_op25.so(_ZN15op25_decoder_bf14receive_symbolEh+0x18c)[0xb2cffbec]
/usr/local/lib/python2.7/dist-packages/gnuradio/_op25.so(_ZN15op25_decoder_bf12general_workEiRSt6vectorIiSaIiEERS0_IPKvSaIS5_EERS0_IPvSaIS9_EE+0x4b)[0xb2cffddb]
/usr/local/lib/libgnuradio-core-3.6.3.1.so.0.0.0(_ZN17gr_block_executor17run_one_iterationEv+0xa09)[0xb6aa5529]
/usr/local/lib/libgnuradio-core-3.6.3.1.so.0.0.0(_ZN18gr_tpb_thread_bodyC1EN5boost10shared_ptrI8gr_blockEEi+0x4b1)[0xb6ac7aa1]
/usr/local/lib/libgnuradio-core-3.6.3.1.so.0.0.0(+0xb335b)[0xb6ac235b]
/usr/local/lib/libgruel-3.6.3.1.so.0.0.0(+0x32e46)[0xb6c6ae46]
/usr/lib/libboost_thread.so.1.49.0(+0xb96c)[0xb68f096c]
/lib/i386-linux-gnu/libpthread.so.0(+0x6d4c)[0xb76c5d4c]
/lib/i386-linux-gnu/libc.so.6(clone+0x5e)[0xb75e0dde]
======= Memory map: ========
i omitted the huge memory map. i have no idea what to do with this sort
of back trace. any guidance will be much appreciated.
Cheers,
Matt
