[Discuss-gnuradio] FFTW 3.1/ PortAudio
On building FFTW3.1 the following works configure --enable-sse --enable-threads --enable-shared --enable-float --enable-3dnow --enable-k7 and --enable-shared do not work together but 3dnow works with shared. Go figure. This library has been tested on my P4HT, Dual Athlon MP, 8 head Athlon Dual Core Opteron, and through MinGW on my windows machines. On Winblows --enable-threads does not work yet and in addition one must use --with-our-malloc16 to prevent certain problems on Windows and the win32 malloc. Cygwin has released pthreads-win32 and it works as a native win32 library. This is probably the basis for pthreads under cygwin so I will attempt to do the library under cygwin to see if we can get thread safer code. Frank and I use pthreads in the Win32 version of DttSP. I am looking for a bug in my callback under portaudio on DttSP. This will enable us to cross platform DttSP on linux, bsd, mac, and wintel. I have built gr-audio-portaudio but I want to make sure that it supports a rich enough set of features to use libportaudio and pa19.dll on linux and winblows respectively which is the only real reason for using portaudio. I will ask for help here and elsewhere with talking to coreaudio since I do not own a mac machine and the ones I have at work are locked in. It is my belief that this will really make gnuradio-win32 a possibility after all the great work done by DvH, Fillod, etc. Bob -- AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman Laziness is the number one inspiration for ingenuity. Guilty as charged! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FFTW 3.1/ PortAudio
On Sun, Mar 12, 2006 at 01:29:55PM -0500, Robert McGwier wrote: [..] I am looking for a bug in my callback under portaudio on DttSP. This will enable us to cross platform DttSP on linux, bsd, mac, and wintel. I have built gr-audio-portaudio but I want to make sure that it supports gr-audio-portaudio ? I am on it. Have you done something more than what is in the current CVS repository? I rewrote something, and it's almost done (it would have been if there was no rugby game this afternoon :). In a way, the API is similar to JACK. The first samples are coming out. -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Simulateous transmission from two daughterboards - I've got it !
I think I've got it, Eric. According to usrp_standard.h the set_mux method understand the mux value a differente way... BTW does the same mux value works for rx way? Angilberto. --- Angilberto Muniz Sb [EMAIL PROTECTED] wrote: Eric, it works but theres something I dont understand... No matter of what I put in the self.u.set_mux(0x) I always get 1st signal out to tx board A and 2nd signal out to tx board B. I suppose I could switch output channels just swapping the mux values... Also, according to usrp_standard.cc mux values should be 0,1,2 or 3. How come the example uses a, b, 9 and 8 ?! -- Im totally lost... Angilberto. --- Eric Blossom [EMAIL PROTECTED] wrote: On Sun, Mar 05, 2006 at 02:21:55AM -0500, Satashu Goel wrote: I am trying to find some information on how to use the two Tx daughterboards to transmit independent data streams? In one of the posts, http://lists.gnu.org/archive/html/discuss-gnuradio/2005-10/msg00142.html Eric said that this can be done by using a stream with two interleaved channels of I Q data. Does anyone know how to do this using the existing blocks? It will be great if someone can post an example. Thanks, Satashu OK, I've got your example ready. It runs with any kind of daughterboard on either side. Here's an example of running it with a basic Tx on side A and a flex 400 on B: [EMAIL PROTECTED] usrp]$ ./fm_tx_2_daughterboards.py 10M 446.1M Using TX d'board A: Basic Tx Using TX d'board B: Flex 400 Tx Tuning side A to 10MHz r.baseband_freq = 0 r.dxc_freq = 10M r.residual_freq = 0 r.inverted = False OK Tuning side B to 446.1MHz r.baseband_freq = 450M r.dxc_freq = -3.9M r.residual_freq = -381.47m r.inverted = False OK Enter ^C to kill it. It puts out SSB (USB) signals. Side A gets a 600 Hz tone. Side B gets 350 + 440 Hz (US dial tone). You should be able to hear these with a suitable receiver. Worked for me ;) It's checked in as gnuradio-examples/python/usrp/fm_tx_2_daughterboards.py and is also attached.Yes, you could consider having to manually interleave the output streams a bug. Eric #!/usr/bin/env python Transmit 2 signals, one out each daughterboard. Outputs SSB (USB) signals on side A and side B at frequencies specified on command line. Side A is 600 Hz tone. Side B is 350 + 440 Hz tones. from gnuradio import gr from gnuradio.eng_notation import num_to_str, str_to_num from gnuradio import usrp from gnuradio import audio from gnuradio import blks from gnuradio.eng_option import eng_option from optparse import OptionParser import usrp_dbid import math import sys class example_signal_0(gr.hier_block): Sinusoid at 600 Hz. def __init__(self, fg, sample_rate): src = gr.sig_source_c (sample_rate,# sample rate gr.GR_SIN_WAVE, # waveform type 600,# frequency 1.0,# amplitude 0) # DC Offset gr.hier_block.__init__(self, fg, None, src) class example_signal_1(gr.hier_block): North American dial tone (350 + 440 Hz). def __init__(self, fg, sample_rate): src0 = gr.sig_source_c (sample_rate,# sample rate gr.GR_SIN_WAVE, # waveform type 350,# frequency 1.0,# amplitude 0) # DC Offset src1 = gr.sig_source_c (sample_rate,# sample rate gr.GR_SIN_WAVE, # waveform type 440,# frequency 1.0,# amplitude 0) # DC Offset sum = gr.add_cc() fg.connect(src0, (sum, 0)) fg.connect(src1, (sum, 1)) gr.hier_block.__init__(self, fg, None, sum) class my_graph(gr.flow_graph): def __init__(self): gr.flow_graph.__init__ (self) usage=%prog: [options] side-A-tx-freq side-B-tx-freq parser = OptionParser (option_class=eng_option, usage=usage) (options, args) = parser.parse_args () if len(args) != 2: parser.print_help() raise SystemExit else: freq0 = str_to_num(args[0]) freq1 = str_to_num(args[1]) # # Set up USRP to transmit on both daughterboards
[Discuss-gnuradio] usb and lsb transmission
Today i dedicated my spare time to the tx basci board, experimenting with usb, lsb and am signal synth. The idea was tp get voice from pc microphone and usb or lsb modulate it. I used a phasing modulator, based on the code excerpt reported below; basically I apply a pass band to the float source, then an hilbert filter followed by a software interpolation, to finish with the usrp interpolating the final jump to 128MS. To my surprise, I got USB with this graph, and i had to conjugate the output of the hilbert filter to get the LSB. That is because in my mind i had modelized the tx path of the usrp as the usual NCO (sine and cosine) multiplied by the real and imaginary stream arriving from usb and an ADDER in the end. Now, from what I recall, if I sum I should get LSB and if I subtract i should get USB; here it looks like it behaves the other way around. Any explanation for that? ciao Matteo iz2eeq audio_rate = 32000 sw_interp = 8 usrp_interp = 512 fg = gr.flow_graph () ampl = 2 src0 = gr.sig_source_f (audio_rate, gr.GR_SIN_WAVE, 700 , ampl) src2 = audio.source(audio_rate) moni = audio.sink(audio_rate) gain = gr.multiply_const_ff (2) interp_taps = gr.firdes.band_pass (sw_interp, audio_rate*sw_interp, 300, 3300, 1000, gr.firdes.WIN_HANN) print len(interp_taps) hilb_taps = gr.firdes.hilbert(199) hilb_filt = gr.filter_delay_fc(hilb_taps) interp = gr.interp_fir_filter_ccf (sw_interp, interp_taps) conj = gr.conjugate_cc() u = usrp.sink_c (0, usrp_interp) tx_subdev_spec = usrp.pick_tx_subdevice(u) m = usrp.determine_tx_mux_value(u, tx_subdev_spec) print mux = %#04x % (m,) u.set_mux(m) subdev = usrp.selected_subdev(u, tx_subdev_spec) print Using TX d'board %s % (subdev.side_and_name(),) print Gain Range %s % (subdev.gain_range(),) u.set_tx_freq (0, cordic_freq) u.set_pga(0,0) fg.connect (src2, gain) fg.connect (gain, hilb_filt) #fg.connect (src1,hilb_filt) fg.connect (hilb_filt,interp) fg.connect (interp,conj) fg.connect (conj,u) #LSB #fg.connect (interp, u)#USB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FFTW 3.1/ PortAudio
Just yesterday I was considering writing a gr-audio-mac block. But now I will certainly not do that. So, if you guys need mac os x testers, I am more than happy to help. Thomas On 3/12/06, Stephane Fillod [EMAIL PROTECTED] wrote: On Sun, Mar 12, 2006 at 01:29:55PM -0500, Robert McGwier wrote: [..] I am looking for a bug in my callback under portaudio on DttSP. This will enable us to cross platform DttSP on linux, bsd, mac, and wintel. I have built gr-audio-portaudio but I want to make sure that it supports gr-audio-portaudio ? I am on it. Have you done something more than what is in the current CVS repository? I rewrote something, and it's almost done (it would have been if there was no rugby game this afternoon :). In a way, the API is similar to JACK. The first samples are coming out. -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FFTW 3.1/ PortAudio
That is why I put the message out. It will be good to have a working starting point. Bob Stephane Fillod wrote: On Sun, Mar 12, 2006 at 01:29:55PM -0500, Robert McGwier wrote: [..] I am looking for a bug in my callback under portaudio on DttSP. This will enable us to cross platform DttSP on linux, bsd, mac, and wintel. I have built gr-audio-portaudio but I want to make sure that it supports gr-audio-portaudio ? I am on it. Have you done something more than what is in the current CVS repository? I rewrote something, and it's almost done (it would have been if there was no rugby game this afternoon :). In a way, the API is similar to JACK. The first samples are coming out. -- AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman Laziness is the number one inspiration for ingenuity. Guilty as charged! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Portaudio
Some important fixes have been made in the last two weeks and that group is really starting to come alive since Audacity and Debian both threatened them with removal from their projects if they did not get their V19 version out the door. That has helped tremendously. I am adding WAVEFORMATEXTENSIBLE to wmme so they can support 5.1 speakers (for example) so I am holding my nose and helping them with windows. Arve Knudsen with input from several new Debian and Audacity contributors have moved Linux along nicely. Bjorn Roche has really been moving the coreaudio stuff along as well as helping with Linux. Eric Wachsmann made wdm-ks work for the first time ever and it is solid. I can see the end game on V19 being released from development to stable. It will be important to stay current: cvs -d:pserver:[EMAIL PROTECTED]:/home/cvs co -r v19-devel portaudio v18 is almost useless. Bob -- AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman Laziness is the number one inspiration for ingenuity. Guilty as charged! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] initial gr-audio-portaudio
On Sun, Mar 12, 2006 at 02:36:21PM -0500, Robert McGwier wrote:
That is why I put the message out. It will be good to have a working
starting point.
Okay, there it is. Just checked in to gr-audio-portaudio repository.
It's somewhat working, but there's still some static in the audio
output (tested with ALSA playback, mono and stereo). Some more work
is needed.
You will need the attached patchs:
- against gnuradio-core: ot_gri_ringbuffer.patch
* src/lib/omnithread/omnithread.h: add omni_mutex::trylock
* src/lib/general/gri_ringbuffer.{cc,h},
src/lib/general/Makefile.am: new lockless ringbuffer (single
reader/single writer) taken from JACK software (GPL).
- against portaudio-V19(CVS): portaudio-pkg-config.patch
* pkg-config .pc file with proper THREAD_FLAGS
The code should be portable. I was missing the native Win32 call for
mutex_trylock, so someone will have to find it, and define
OMNI_MUTEX_TRYLOCK_IMPLEMENTATION in src/lib/omnithread/ot_nt.h,
with appropriate semantic (return value).
The gri_pa_find_device_by_name() function will have to be made more
smart, like accepting which HostApi (ALSA, JACK, ..) is to be chosen,
and which device from this API. A syntax will have to be agreed upon,
like ALSA:hw:0 or OSS:/dev/dsp1.
Have fun,
--
Stephane
Index: src/lib/general/Makefile.am
===
RCS file: /sources/gnuradio/gnuradio-core/src/lib/general/Makefile.am,v
retrieving revision 1.83
diff -u -b -B -w -p -r1.83 Makefile.am
--- src/lib/general/Makefile.am 23 Feb 2006 21:26:29 - 1.83
+++ src/lib/general/Makefile.am 12 Mar 2006 20:55:14 -
@@ -187,6 +187,7 @@ libgeneral_la_SOURCES = \
gri_char_to_float.cc\
gri_uchar_to_float.cc \
gri_interleaved_short_to_complex.cc \
+ gri_ringbuffer.cc \
malloc16.c
libgeneral_qa_la_SOURCES = \
@@ -302,6 +303,7 @@ grinclude_HEADERS = \
gri_lfsr_32k.h \
gri_short_to_float.h\
gri_char_to_float.h \
+ gri_ringbuffer.h\
gri_uchar_to_float.h\
random.h
Index: src/lib/omnithread/omnithread.h
===
RCS file: /sources/gnuradio/gnuradio-core/src/lib/omnithread/omnithread.h,v
retrieving revision 1.1.1.1
diff -u -b -B -w -p -r1.1.1.1 omnithread.h
--- src/lib/omnithread/omnithread.h 10 Apr 2004 18:00:52 - 1.1.1.1
+++ src/lib/omnithread/omnithread.h 12 Mar 2006 20:55:19 -
@@ -145,6 +145,7 @@ class omni_thread;
#if (!defined(OMNI_MUTEX_IMPLEMENTATION)|| \
!defined(OMNI_MUTEX_LOCK_IMPLEMENTATION) || \
+ !defined(OMNI_MUTEX_TRYLOCK_IMPLEMENTATION)|| \
!defined(OMNI_MUTEX_UNLOCK_IMPLEMENTATION) || \
!defined(OMNI_CONDITION_IMPLEMENTATION)|| \
!defined(OMNI_SEMAPHORE_IMPLEMENTATION)|| \
@@ -186,6 +187,10 @@ public:
inline void lock(void){ OMNI_MUTEX_LOCK_IMPLEMENTATION }
inline void unlock(void) { OMNI_MUTEX_UNLOCK_IMPLEMENTATION }
+inline int trylock(void) { return OMNI_MUTEX_TRYLOCK_IMPLEMENTATION }
+ // if mutex is unlocked, lock it and return 1 (true).
+ // If it's already locked then return 0 (false).
+
inline void acquire(void) { lock(); }
inline void release(void) { unlock(); }
// the names lock and unlock are preferred over acquire and release
Index: src/lib/omnithread/ot_posix.h
===
RCS file: /sources/gnuradio/gnuradio-core/src/lib/omnithread/ot_posix.h,v
retrieving revision 1.1.1.1
diff -u -b -B -w -p -r1.1.1.1 ot_posix.h
--- src/lib/omnithread/ot_posix.h 10 Apr 2004 18:00:52 - 1.1.1.1
+++ src/lib/omnithread/ot_posix.h 12 Mar 2006 20:55:19 -
@@ -57,6 +57,9 @@ extern C void* omni_thread_wrapper(voi
#define OMNI_MUTEX_LOCK_IMPLEMENTATION \
pthread_mutex_lock(posix_mutex);
+#define OMNI_MUTEX_TRYLOCK_IMPLEMENTATION \
+pthread_mutex_trylock(posix_mutex);
+
#define OMNI_MUTEX_UNLOCK_IMPLEMENTATION\
pthread_mutex_unlock(posix_mutex);
--- /dev/null 2006-03-10 00:02:48.821312048 +0100
+++ src/lib/general/gri_ringbuffer.h2006-03-12 20:05:46.0 +0100
@@ -0,0 +1,203 @@
+/* -*- c++ -*- */
+/*
+ * Copyright 2006 Free Software Foundation, Inc.
+ *
+ * This file is part of GNU Radio
+ *
+ * GNU Radio is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2, or (at your option)
+ * any later version.
+ *
+ * GNU Radio is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied
Re: [Discuss-gnuradio] initial gr-audio-portaudio
Stephane Fillod wrote: On Sun, Mar 12, 2006 at 02:36:21PM -0500, Robert McGwier wrote: That is why I put the message out. It will be good to have a working starting point. Okay, there it is. Just checked in to gr-audio-portaudio repository. It's somewhat working, but there's still some static in the audio output (tested with ALSA playback, mono and stereo). Some more work is needed. You will need the attached patchs: Awesome. -- AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman Laziness is the number one inspiration for ingenuity. Guilty as charged! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SuSE 10.0 build experience
On Sunday 12 March 2006 07:55, Lamar Owen wrote: On Tuesday 07 March 2006 23:01, Berndt Josef Wulf wrote: On Wednesday 08 March 2006 13:05, Eric Blossom wrote: My DVD, whilst providing most development tools, didn't have gnu gcc and g++. It was missing and I had to build it from sources. sdcc is missing too and I have yet to build it. The Linux Magazine SuSE 10.0 'non-OSS' DVD perhaps? You need to point YaST at an online installer and off of the DVD once you install, then grab the other bits you need. There's lots missing on that DVD, like PostgreSQL I got one of those, too, and getting it 'fixed' took a little while. Linux Magazine's site has information (this is the UK Linux Magazine, BTW) Thanks, yes its the DVD from linux-magazine.com. I've since upgraded to 10.1-beta6. Whilst the Suse installation process is as smooth as it can get, it is unfortunately pretty rough around the edges when it comes to installing packages using YaST2. Many packages are missing, some packages don't come with their *-devel companions and some don't even exist requiring building from sources. I installed and tested GNU Radio on RH9, FC4 and Suse 10.0/10.1b6. FC4 sofar delivered the best results for me. However, none of the Linux distributions offered me the ease of installing GNU Radio that comes with pkgsrc. Its most definitely not an automated process and a big stumbling block for newcomers. Next I will try to bootstrap pkgsrc on Suse and try installing GNU Radio from there. Another interesting exercise would be to use LINUX XEN0 to run a NetBSD XENU domain and run the NetBSD binaries for GNU Radio. cheerio Berndt pgp0TfXfgYGpT.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SuSE 10.0 build experience
On Mon, Mar 13, 2006 at 11:08:44AM +1030, Berndt Josef Wulf wrote: On Sunday 12 March 2006 07:55, Lamar Owen wrote: On Tuesday 07 March 2006 23:01, Berndt Josef Wulf wrote: On Wednesday 08 March 2006 13:05, Eric Blossom wrote: My DVD, whilst providing most development tools, didn't have gnu gcc and g++. It was missing and I had to build it from sources. sdcc is missing too and I have yet to build it. The Linux Magazine SuSE 10.0 'non-OSS' DVD perhaps? You need to point YaST at an online installer and off of the DVD once you install, then grab the other bits you need. There's lots missing on that DVD, like PostgreSQL I got one of those, too, and getting it 'fixed' took a little while. Linux Magazine's site has information (this is the UK Linux Magazine, BTW) Thanks, yes its the DVD from linux-magazine.com. I've since upgraded to 10.1-beta6. Whilst the Suse installation process is as smooth as it can get, it is unfortunately pretty rough around the edges when it comes to installing packages using YaST2. Many packages are missing, some packages don't come with their *-devel companions and some don't even exist requiring building from sources. I think the problem is that everything doesn't fit on the single-layer DVD image that you can download for free. If you pay a few bucks, they'll send you a double-layer DVD that's got everything you need, or I think there are mirrors somewhere with the missing packages. Explanation here: http://www.novell.com/coolsolutions/tip/16076.html Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] initial gr-audio-portaudio
Hi Stephane,
Is it possible that the portaudio patch of yours is missing the
portauido.pc target? I get errors if I want to install it, i.e., it
tells me that there is no portaudio.pc target.
Thomas
On 3/12/06, Stephane Fillod [EMAIL PROTECTED] wrote:
On Sun, Mar 12, 2006 at 02:36:21PM -0500, Robert McGwier wrote:
That is why I put the message out. It will be good to have a working
starting point.
Okay, there it is. Just checked in to gr-audio-portaudio repository.
It's somewhat working, but there's still some static in the audio
output (tested with ALSA playback, mono and stereo). Some more work
is needed.
You will need the attached patchs:
- against gnuradio-core: ot_gri_ringbuffer.patch
* src/lib/omnithread/omnithread.h: add omni_mutex::trylock
* src/lib/general/gri_ringbuffer.{cc,h},
src/lib/general/Makefile.am: new lockless ringbuffer (single
reader/single writer) taken from JACK software (GPL).
- against portaudio-V19(CVS): portaudio-pkg-config.patch
* pkg-config .pc file with proper THREAD_FLAGS
The code should be portable. I was missing the native Win32 call for
mutex_trylock, so someone will have to find it, and define
OMNI_MUTEX_TRYLOCK_IMPLEMENTATION in src/lib/omnithread/ot_nt.h,
with appropriate semantic (return value).
The gri_pa_find_device_by_name() function will have to be made more
smart, like accepting which HostApi (ALSA, JACK, ..) is to be chosen,
and which device from this API. A syntax will have to be agreed upon,
like ALSA:hw:0 or OSS:/dev/dsp1.
Have fun,
--
Stephane
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gri_ringbuffer.{h,cc}
No. The problem was caused by our own error. Under some pathological
conditions you want to reset the ring buffers and start over. We talked
ourselves into believing all off this was protected and we were just
plain wrong. I made the initial error and Frank recaptured the error in
beautiful code.
The final resolution: if you find pathologies in the ring buffers, the
ONLY safe place to reset them is in the callback itself, otherwise the
callback can /**AND WILL**/ step on the rb reset. You cannot afford to
semaphore, etc. in the callback of course, so a safe way is to use flags
that are only read and reset in the callback when the rb resets occur.
There are subtle race conditions that might occur but they are minor
irritants compared to the stupidity of what we were doing.
All of the strange conditions we had in DttSP were caused by this
programming bug. They no longer exist in DttSP v.2 which will be out
next week and they don't exist in PowerSDR now. We only looked for this
subtlety for months. A few well constructed tests finally resolved the
problem.
Bob
Eric Blossom wrote:
On Sun, Mar 12, 2006 at 10:20:16PM +0100, Stephane Fillod wrote:
- against gnuradio-core: ot_gri_ringbuffer.patch
* src/lib/general/gri_ringbuffer.{cc,h},
src/lib/general/Makefile.am: new lockless ringbuffer (single
reader/single writer) taken from JACK software (GPL).
Bob and Frank,
Didn't the JACK ringbuffer code cause you problems when pushing part
of a float into it. I.e., there was room for 3 bytes, but not all
four. If this is true, how did you fix it? Specialize for only
floats? Yet another ringbuffer implementation that doesn't have
the problem? I can't see an occasion when we'd need anything other
than floats.
Eric
--
AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats,
NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman
Laziness is the number one inspiration for ingenuity. Guilty as charged!
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] initial gr-audio-portaudio
Yes. This is an error. To get started I just manually constructed
portaudio.pc and started work on gr-audio-portaudio. After we get the
appropriate fix to Makefile.in in the portaudio build, we should open
gr-audio-portaudio. It is ready for us all to beat on it and find the
problems.
Bob
Thomas Schmid wrote:
Hi Stephane,
Is it possible that the portaudio patch of yours is missing the
portauido.pc target? I get errors if I want to install it, i.e., it
tells me that there is no portaudio.pc target.
Thomas
On 3/12/06, Stephane Fillod [EMAIL PROTECTED] wrote:
On Sun, Mar 12, 2006 at 02:36:21PM -0500, Robert McGwier wrote:
That is why I put the message out. It will be good to have a working
starting point.
Okay, there it is. Just checked in to gr-audio-portaudio repository.
It's somewhat working, but there's still some static in the audio
output (tested with ALSA playback, mono and stereo). Some more work
is needed.
You will need the attached patchs:
- against gnuradio-core: ot_gri_ringbuffer.patch
* src/lib/omnithread/omnithread.h: add omni_mutex::trylock
* src/lib/general/gri_ringbuffer.{cc,h},
src/lib/general/Makefile.am: new lockless ringbuffer (single
reader/single writer) taken from JACK software (GPL).
- against portaudio-V19(CVS): portaudio-pkg-config.patch
* pkg-config .pc file with proper THREAD_FLAGS
The code should be portable. I was missing the native Win32 call for
mutex_trylock, so someone will have to find it, and define
OMNI_MUTEX_TRYLOCK_IMPLEMENTATION in src/lib/omnithread/ot_nt.h,
with appropriate semantic (return value).
The gri_pa_find_device_by_name() function will have to be made more
smart, like accepting which HostApi (ALSA, JACK, ..) is to be chosen,
and which device from this API. A syntax will have to be agreed upon,
like ALSA:hw:0 or OSS:/dev/dsp1.
Have fun,
--
Stephane
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats,
NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman
Laziness is the number one inspiration for ingenuity. Guilty as charged!
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Capture and replay (usrp_rx_cfile.py)
On Mon, Mar 13, 2006 at 11:26:12AM +0800, [EMAIL PROTECTED] wrote: Hi, all Is there any script which is capable to replay the captured file generated by the usrp_rx_cfile.py? It is better if I can choose either the basic TX board (baseband only) or the USRP TVRX board (RF upconversion). FYI, the TVRX board does not transmit. I dare not to try to cook my own script because it seems that interpolator portion is done inside the ADI 9862 chip and I am unsure how to programm it correctly. An rough example would be very helpful! There is no existing program that does exactly what you want, but it's not tricky. Take a look at fm_tx4.py, and ignore all the code that generates the multiple fm signals. Just replace all that with a gr.file_source(gr.sizeof_gr_complex, my_file.dat), connect it to self.u and you'll be good to go. All you have to do to set the interpolation rate is to call self.u.set_interp_rate(interp_factor), just like in the example. We've spent a lot of time trying to make it easy ;) Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gri_ringbuffer.{h,cc}
Frank Brickle wrote: Robert McGwier wrote: There are subtle race conditions that might occur but they are minor irritants compared to the stupidity of what we were doing. In particular you'd want to make sure any values that can be read in the callback are set atomically in the client code. That includes flags that trigger resets in the callback. Bob's recounting of our joint mental blunder is a little oversimplified. My operating principle was that, once the callback is started, the ring buffers are *never* reset. This is correct in principle but unworkable in practice. Unfortunately the resets were kind of wedged into the code and not properly thought out, by me mostly. Actually, this exact same error was in and DID occur in the dead bug version naked buffer exchange code . On PTT I memset the buffer to zero to stop transmit noise from entering receiver code and vice versa. And of course, the callback can and did overwrite this operation. There is enough ooopsie to go around on this one for sure. The proper way to do this, of course, would be via something like an around method applied to the callback. Since that's not a possibility, the correct thing is still to wrap a ring buffer management layer around the jack buffer processing, but all inside the callback routine itself. Frank -- AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman Laziness is the number one inspiration for ingenuity. Guilty as charged! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gri_ringbuffer.{h,cc}
On Sun, Mar 12, 2006 at 06:03:39PM -0800, Eric Blossom wrote:
On Sun, Mar 12, 2006 at 10:20:16PM +0100, Stephane Fillod wrote:
- against gnuradio-core: ot_gri_ringbuffer.patch
* src/lib/general/gri_ringbuffer.{cc,h},
src/lib/general/Makefile.am: new lockless ringbuffer (single
reader/single writer) taken from JACK software (GPL).
Bob and Frank,
Didn't the JACK ringbuffer code cause you problems when pushing part
of a float into it. I.e., there was room for 3 bytes, but not all
four. If this is true, how did you fix it? Specialize for only
floats? Yet another ringbuffer implementation that doesn't have
the problem? I can't see an occasion when we'd need anything other
than floats.
Answering my own question, I guess as long as you use write_space and
round down prior to writing, everything should work fine.
Yes, this is exactly what is done in gr-audio-{jack,portaudio}.
Look at the lines like this:
write_space -= write_space%buffer_size_bytes;
write_size = std::min(write_space, (unsigned int)work_size);
The ringbuffer max usable size is an exponent of two, minus one. Hence you
end up pushing partial objects into it if no care is taken when the
ringbuffer is full.
In the end, no need to specialize it.
--
Stephane
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] initial gr-audio-portaudio
Hi Thomas, On Sun, Mar 12, 2006 at 06:30:19PM -0800, Thomas Schmid wrote: Hi Stephane, Is it possible that the portaudio patch of yours is missing the portauido.pc target? I get errors if I want to install it, i.e., it tells me that there is no portaudio.pc target. Have you run aclocal ; autoconf before running again the configure script of portaudio? This should take care of making to appear the portaudio.pc file. -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] initial gr-audio-portaudio
On Sun, Mar 12, 2006 at 07:14:15PM -0800, Thomas Schmid wrote: I tried your code on Mac OS X 10.4 and I get pretty far (everything compiles and isntalls after some hacking), but when I execute an audio example, I get this error: 19:04 [EMAIL PROTECTED]:~/gnuradio/gr-build/gnuradio-examples/python/audio$ ./dial_tone.py Traceback (most recent call last): File ./dial_tone.py, line 55, in ? my_graph().run() File ./dial_tone.py, line 48, in __init__ dst = audio.sink (sample_rate, options.audio_output) File /Users/thomas/gnuradio/gr/lib/python2.4/site-packages/gnuradio/audio_portaudio.py, line 235, in sink return _audio_portaudio.sink(*args) NotImplementedError: No matching function for overloaded 'sink' Now I am stuck. Any idea why this happens or what could be wrong? Most likely the arguments are not what is expected. Looking at gr-audio-portaudio/src/audio_portaudio.i, they should be: audio_portaudio_sink (int sampling_freq, int ok_to_block, const std::string device_name ) device_name defaults to , and ok_to_block defaults to 1. Eric, the argument order may be tweaked. Here is what I did, if anyone wants to repeat it: - install xcode 2.2 - install coreaudio sdk 1.4.3 - downloaded portaudio V19 and applied patch - fixed small -framework error on line 144 of configure.in (remove double -framework) - fixed also -framework error in Makefile.in We should definitely add automake/libtool support to portaudio. - removed the portaudio.pc directives which were added from the patch (no portaudio.pc target in the makefile, will do it manually later on. i think it is missing.) Look at my other mail. This should not be necessary if built from scratch. -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
