[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] Hilbert filter design gain low using gr_firdes::hilbert
Terry Barnaby wrote: Hi, I note that the gr_firdes::hilbert() routine and hence the hilbert_fc process does not have a gain of 1 for low numbers of taps (gain of 0.3 for 155 taps). Is this correct ? Cheers Terry ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio Hi, Ignore the previous email. The frequency I was using was much lower than I thought and was off the bottom of the envolope. Terry ___ 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) > > (option
[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
Re: [Discuss-gnuradio] FFTW 3.1/ PortAudio
Good. Let's get it on. Bob Thomas Schmid wrote: 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 -- 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
Robert McGwier wrote: > 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. You can test building it on a mac using the sourceforge compile farm. They have two macos-X machines (and lots of other architectures) http://sourceforge.net/docs/E02/en/#top I have been doing some tests on the sourceforge compile farm to see if we can use it for automatic build testing for gnuradio and usrp. (You have to setup all your required libs in your homedirectory. I have succefully build the usrp driver code on their debian-linux X86 machine.) Since this is a remote machine, you can't hear anything of couse ;-) Greetings, Martin It is my belief that this will really make > gnuradio-win32 a possibility after all the great work done by DvH, > Fillod, etc. > > Bob > ___ 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 !
On Sat, Mar 11, 2006 at 07:41:02AM -0800, Angilberto Muniz Sb wrote: > 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. The Tx and Rx mux work differently. from class usrp_standard_rx: /*! * \brief Set input mux configuration. * * This determines which ADC (or constant zero) is connected to * each DDC input. There are 4 DDCs. Each has two inputs. * * * Mux value: * *3 2 1 * 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 * +---+---+---+---+---+---+---+---+ * | Q3 | I3 | Q2 | I2 | Q1 | I1 | Q0 | I0 | * +---+---+---+---+---+---+---+---+ * * Each 4-bit I field is either 0,1,2,3 * Each 4-bit Q field is either 0,1,2,3 or 0xf (input is const zero) * All Q's must be 0xf or none of them may be 0xf * */ bool set_mux (int mux); from class usrp_standard_tx: /*! * \brief Set output mux configuration. * * * 3 2 1 * 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 * +---+---+---+---+---+ * | | DAC3 | DAC2 | DAC1 | DAC0 | * +---+---+---+---+---+ * * There are two interpolators with complex inputs and outputs. * There are four DACs. * * Each 4-bit DACx field specifies the source for the DAC and * whether or not that DAC is enabled. Each subfield is coded * like this: * * 3 2 1 0 *+-+-+ *|E| N | *+-+-+ * * Where E is set if the DAC is enabled, and N specifies which * interpolator output is connected to this DAC. * * N which interp output * --- --- * 0 chan 0 I * 1 chan 0 Q * 2 chan 1 I * 3 chan 1 Q * */ bool set_mux (int mux); ___ 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
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] initial gr-audio-portaudio
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?
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
- 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.)
- make; make install
- applied patch to gnuradio-core
- add gr-portaudio to audio.py in src/python/gnuradio (or replace the
audio_osx one, as you wish)
- make; make install
- produce my own portaudio.pc file
- remove the -mthreads library from that file
- make gr-portaudio
that's it...
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
[Discuss-gnuradio] Capture and replay (usrp_rx_cfile.py)
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). 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! Owen Wu ASMedia ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gri_ringbuffer.{h,cc}
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. 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 ___ 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
[Discuss-gnuradio] Re: Simple example gr-audio-portaudio
On Mon, Mar 13, 2006 at 02:36:24AM -0500, Robert McGwier wrote: > Stephane: > > Can you give a modification of audio_copy.py and audio_play.py that use > jack and portaudio? I do not seem to get the required syntax. Here we go. Cc'd to the list since this is going to be a FAQ :-) Index: mono_tone.py === RCS file: /sources/gnuradio/gnuradio-examples/python/audio/mono_tone.py,v retrieving revision 1.4 diff -u -b -B -w -p -r1.4 mono_tone.py --- mono_tone.py3 Mar 2006 01:26:52 - 1.4 +++ mono_tone.py13 Mar 2006 07:49:56 - @@ -21,7 +21,7 @@ # from gnuradio import gr -from gnuradio import audio +from gnuradio import audio_portaudio from gnuradio.eng_option import eng_option from optparse import OptionParser @@ -44,7 +44,7 @@ class my_graph(gr.flow_graph): ampl = 0.1 src0 = gr.sig_source_f (sample_rate, gr.GR_SIN_WAVE, 650, ampl) -dst = audio.sink (sample_rate, options.audio_output) +dst = audio_portaudio.sink (sample_rate, 1, options.audio_output) self.connect (src0, (dst, 0)) Index: multi_tone.py === RCS file: /sources/gnuradio/gnuradio-examples/python/audio/multi_tone.py,v retrieving revision 1.3 diff -u -b -B -w -p -r1.3 multi_tone.py --- multi_tone.py 10 Oct 2005 23:17:52 - 1.3 +++ multi_tone.py 13 Mar 2006 07:49:56 - @@ -21,7 +21,7 @@ # from gnuradio import gr -from gnuradio import audio +from gnuradio import audio_portaudio from gnuradio.eng_option import eng_option from optparse import OptionParser @@ -63,7 +63,7 @@ class my_graph(gr.flow_graph): # progression = (7, 11, 1, 5) progression = (7, 11, 1, 5, 9) -dst = audio.sink (sample_rate, options.audio_output) +dst = audio_portaudio.sink (sample_rate, 1, options.audio_output) max_chan = dst.input_signature().max_streams() if (max_chan == -1) or (max_chan > limit_channels): -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
