Re: [Discuss-gnuradio] query regarding wav file recording through wav file sink block

[CEL]

256 kHz is not a sampling rate supported by many devices. What USRP are
you using?

Also, the filename doesn't matter to its content at all, so this is
fine, but using .txt for a file that contains raw binary samples is
questionable.

So, back to your original problem: can you describe how the result of
the operation is different from what you're expecting? I still must
admit I don't get where the problem lies.

Best regards,
Marcus

On Fri, 2019-06-07 at 10:04 +0530, Maitry Raval wrote:
> Hello,
> 
> PLease find attached flowgraph for other end of txt file writing, as
> I have received the transmitted signal through UHD USRP source block
> and record it in a text file at 256k sample rate and then this
> recorded text file is being used in next flow graph for converting it
> into wav file.
> 
> that means I have received the modulated transmitted signal, record
> it in txt file and remove noise as well resample it to 48k in order
> to save that downcoverted signal to wav file sink.
> 
> With Best Regards,
> Maitry Raval,
> 
> - Original Message -
> From: "Marcus Müller, CEL" 
> To: "maitry raval" 
> Cc: "discuss-gnuradio" 
> Sent: Wednesday, 5 June, 2019 07:09:42
> Subject: Re: query regarding wav file recording through wav file sink
> block
> 
> we really need both your Wav writing (we've got that) and Wav reading
> flow graph to make any qualified statement. 
> 
> Again, the file name in your file source is suspicious. 
> 
> Best regards,
> Marcus
> 
> On Wed, 2019-06-05 at 10:54 +0530, Maitry Raval wrote:
> > Hello,
> > 
> > Please check the flowgraph, as there is a wav file sink at output
> > side, that record the incoming signal, but when I use that same
> > recorded wav file in wav file source and check the output in time
> > sink and FFT sink, then amplitude changes.
> > 
> > With Best Regards,
> > Maitry Raval,
> > 
> > 
> > - Original Message -
> > From: "Marcus Müller, CEL" 
> > To: "maitry raval" 
> > Cc: "discuss-gnuradio" 
> > Sent: Tuesday, 4 June, 2019 13:01:55
> > Subject: Re: query regarding wav file recording through wav file
> > sink
> > block
> > 
> > Ok, there's no Wave file involved here; instead, you read a file as
> > complex 2×3bit floating point binary that has a .txt ending. Have
> > you
> > read [1]?
> > Then, you're doing *way* more than just multiplying with a
> > constant,
> > so
> > really, I'm not sure this flow graph has *anything* to do with your
> > question.
> > 
> > [1] 
> > https://wiki.gnuradio.org/index.php/FAQ#What_is_the_file_format_of_a_file_sink.3F_How_can_I_read_files_produced_by_a_file_sink.3F
> > 
> > On Tue, 2019-06-04 at 15:17 +0530, Maitry Raval wrote:
> > > Hello,
> > > 
> > > Please check the flow graph.
> > > 
> > > 
> > > With Best Regards,
> > > Maitry Raval,
> > > 
> > > 
> > > - Original Message -
> > > From: "Marcus Müller, CEL" 
> > > To: "maitry raval" 
> > > Cc: "discuss-gnuradio" 
> > > Sent: Tuesday, 4 June, 2019 08:56:22
> > > Subject: Re: query regarding wav file recording through wav file
> > > sink block
> > > 
> > > Frankly, multiplication with a constant doesn't offer any
> > > benefit.
> > > The
> > > numbers stay the same, just scaled.
> > > 
> > > However, 8 bit might be the giveaway here: are you maybe trying
> > > to
> > > multiply 8 bit numbers with a constant that leads to values
> > > larger
> > > than
> > > what can be represented in 8 bits?
> > > 
> > > A screenshot of your flowgraph rather than just its result would
> > > be
> > > most interesting here.
> > > On Tue, 2019-06-04 at 13:58 +0530, Maitry Raval wrote:
> > > > Hello,
> > > > 
> > > > Thanks for your response.
> > > > 
> > > > My requirement is to use GNU generated wav file into MATLAB.
> > > > But
> > > > when I record the wav file with 48k sample rate and 8 bits per
> > > > sample, my recorded wavfile shows a very low amplitude signal,
> > > > the screenshot is attached, please check.
> > > > 
> > > > 
> > > > With Best Regards,
> > > > Maitry Raval,
> > > > 
> > > > 
> > > > - Original Message -
> > > > From: "Marcus Müller, CEL" 
> > > > To: "maitry raval" 
> > > > Cc: "discuss-gnuradio" 
> > > > Sent: Tuesday, 4 June, 2019 08:02:48
> > > > Subject: Re: query regarding wav file recording through wav
> > > > file
> > > > sink block
> > > > 
> > > > I assume you do the multiplication with a constance to change
> > > > the
> > > > amplitude, and so that's right.
> > > > 
> > > > A multiplication with a constant does however not change the
> > > > shape of
> > > > the signal at all, unless you're running into numerical
> > > > limits. 
> > > > 
> > > > We'll need more info on what exactly you're doing and what
> > > > exactly
> > > > you're seeing.
> > > > 
> > > > Best regards,
> > > > Marcus
> > > > 
> > > > On Tue, 2019-06-04 at 10:22 +0530, Maitry Raval wrote:
> > > > > Hello,
> > > > > And when I use multiply constant block in order to increase
> > > > > the
> > > > > amplitude of the wav file, It slightly change the amplitude
> >

Re: [Discuss-gnuradio] query regarding wav file recording through wav file sink block

[Maitry Raval]

Hello,

PLease find attached flowgraph for other end of txt file writing, as I have 
received the transmitted signal through UHD USRP source block and record it in 
a text file at 256k sample rate and then this recorded text file is being used 
in next flow graph for converting it into wav file.

that means I have received the modulated transmitted signal, record it in txt 
file and remove noise as well resample it to 48k in order to save that 
downcoverted signal to wav file sink.

With Best Regards,
Maitry Raval,

- Original Message -
From: "Marcus Müller, CEL" 
To: "maitry raval" 
Cc: "discuss-gnuradio" 
Sent: Wednesday, 5 June, 2019 07:09:42
Subject: Re: query regarding wav file recording through wav file sink block

we really need both your Wav writing (we've got that) and Wav reading
flow graph to make any qualified statement. 

Again, the file name in your file source is suspicious. 

Best regards,
Marcus

On Wed, 2019-06-05 at 10:54 +0530, Maitry Raval wrote:
> Hello,
> 
> Please check the flowgraph, as there is a wav file sink at output
> side, that record the incoming signal, but when I use that same
> recorded wav file in wav file source and check the output in time
> sink and FFT sink, then amplitude changes.
> 
> With Best Regards,
> Maitry Raval,
> 
> 
> - Original Message -
> From: "Marcus Müller, CEL" 
> To: "maitry raval" 
> Cc: "discuss-gnuradio" 
> Sent: Tuesday, 4 June, 2019 13:01:55
> Subject: Re: query regarding wav file recording through wav file sink
> block
> 
> Ok, there's no Wave file involved here; instead, you read a file as
> complex 2×3bit floating point binary that has a .txt ending. Have you
> read [1]?
> Then, you're doing *way* more than just multiplying with a constant,
> so
> really, I'm not sure this flow graph has *anything* to do with your
> question.
> 
> [1] 
> https://wiki.gnuradio.org/index.php/FAQ#What_is_the_file_format_of_a_file_sink.3F_How_can_I_read_files_produced_by_a_file_sink.3F
> 
> On Tue, 2019-06-04 at 15:17 +0530, Maitry Raval wrote:
> > Hello,
> > 
> > Please check the flow graph.
> > 
> > 
> > With Best Regards,
> > Maitry Raval,
> > 
> > 
> > - Original Message -
> > From: "Marcus Müller, CEL" 
> > To: "maitry raval" 
> > Cc: "discuss-gnuradio" 
> > Sent: Tuesday, 4 June, 2019 08:56:22
> > Subject: Re: query regarding wav file recording through wav file
> > sink block
> > 
> > Frankly, multiplication with a constant doesn't offer any benefit.
> > The
> > numbers stay the same, just scaled.
> > 
> > However, 8 bit might be the giveaway here: are you maybe trying to
> > multiply 8 bit numbers with a constant that leads to values larger
> > than
> > what can be represented in 8 bits?
> > 
> > A screenshot of your flowgraph rather than just its result would be
> > most interesting here.
> > On Tue, 2019-06-04 at 13:58 +0530, Maitry Raval wrote:
> > > Hello,
> > > 
> > > Thanks for your response.
> > > 
> > > My requirement is to use GNU generated wav file into MATLAB. But
> > > when I record the wav file with 48k sample rate and 8 bits per
> > > sample, my recorded wavfile shows a very low amplitude signal,
> > > the screenshot is attached, please check.
> > > 
> > > 
> > > With Best Regards,
> > > Maitry Raval,
> > > 
> > > 
> > > - Original Message -
> > > From: "Marcus Müller, CEL" 
> > > To: "maitry raval" 
> > > Cc: "discuss-gnuradio" 
> > > Sent: Tuesday, 4 June, 2019 08:02:48
> > > Subject: Re: query regarding wav file recording through wav file
> > > sink block
> > > 
> > > I assume you do the multiplication with a constance to change the
> > > amplitude, and so that's right.
> > > 
> > > A multiplication with a constant does however not change the
> > > shape of
> > > the signal at all, unless you're running into numerical limits. 
> > > 
> > > We'll need more info on what exactly you're doing and what
> > > exactly
> > > you're seeing.
> > > 
> > > Best regards,
> > > Marcus
> > > 
> > > On Tue, 2019-06-04 at 10:22 +0530, Maitry Raval wrote:
> > > > Hello,
> > > > And when I use multiply constant block in order to increase the
> > > > amplitude of the wav file, It slightly change the amplitude and
> > > > change the shape of the signal. PLease someone guide.
> > > > 
> > > > 
> > > > With Best Regards,
> > > > Maitry Raval,
> > > > 
> > > > - Original Message -
> > > > From: "Maitry Raval" 
> > > > To: "Marcus Müller, CEL" 
> > > > Cc: "discuss-gnuradio" 
> > > > Sent: Monday, 3 June, 2019 10:14:11
> > > > Subject: Re: [Discuss-gnuradio] query regarding store
> > > > transmitted signal
> > > > 
> > > > Hello,
> > > > 
> > > > PLease someone guide about wav file recording signal's
> > > > amplitude. as I have a requirement of using GNU generated wav
> > > > file to my application, but as amplitude of wav file is very
> > > > low, I couldnot use that in my application.
> > > > 
> > > > Thanks for your support in advance.
> > > > 
> > > > With Best Regards,
> > > > Maitry Raval,
> > > > 
> > > > - Ori

Re: [Discuss-gnuradio] Getting a Runtime Error: gr::tuntap_pdu::make: tun_alloc failed

[Adrian Musceac]

Hi Eamon,

Tun/tap device creation require your user to have net admin rights, or 
alternatively you can run your flowgraph as root.
See man setcap.

sudo setcap cap_net_raw,cap_net_admin+eip /path/to/program

Regards,
Adrian
 

On June 6, 2019 1:43:35 PM UTC, "Heaney, Eamon"  
wrote:
>Trying to run a modified version of the wifi transceiver from this
>repo:
>https://github.com/bastibl/gr-ieee802-11
>
>Swapped out the USRP source for Osmocom (HackRF), and the USRP sink for
>a
>null sink. When I try to run it, I get this error:
>
>
>Traceback (most recent call last):
>  File
>"/home/galloway/working/seniordesign/gnuradio-companion/wifi_transceiver.py",
>line 343, in 
>main()
>  File
>"/home/galloway/working/seniordesign/gnuradio-companion/wifi_transceiver.py",
>line 331, in main
>tb = top_block_cls()
>  File
>"/home/galloway/working/seniordesign/gnuradio-companion/wifi_transceiver.py",
>line 236, in __init__
>self.blocks_tuntap_pdu_0 = blocks.tuntap_pdu('tap1', 440, False)
>  File
>"/usr/lib64/python2.7/site-packages/gnuradio/blocks/blocks_swig6.py",
>line
>1046, in make
>return _blocks_swig6.tuntap_pdu_make(dev, MTU, istunflag)
>RuntimeError: gr::tuntap_pdu::make: tun_alloc failed (are you running
>as
>root?)
>
>
>
>I am most assuredly *not* running as root, and I'm unsure what
>"gr::tuntap_pdu::make" or "tun_alloc" are. There was one similar email
>chain (https://marc.info/?l=gnuradio-discuss&m=141563926501407&w=2)
>from a
>few years ago, but the solution he found doesn't seem to work; changing
>TUNTAP PDU doesn't fix the problem.
>
>Anyone have a clue as to why these tuntap pdu things are acting up?
>
>-- 
>_The information contained in this communication may be subject to
>legal 
>confidentiality protection or privilege. It is intended solely for use
>by 
>the intended recipient and others authorized to receive it. If you have
>
>received this communication in error, please notify the sender and
>delete 
>it immediately. You are hereby notified that any disclosure, copying, 
>distribution or taking action in reliance of the contents of this 
>information is strictly prohibited and may be unlawful.  The school
>accepts 
>no liability whatsoever for any damage, loss, or expense arising from
>any 
>misuse of this e-mail and/or from the accessing of any files attached
>to 
>this e-mail._
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Help with sound output

[Michael Dickens]

Hi Sara - Can you give us something more to work with, for example a link to 
the Youtube video and another to your code? I'm sure folks here can help, but 
without more info the best we can offer is high-level suggestions on how to fix 
sample rate differences. - MLD

On Thu, Jun 6, 2019, at 12:39 PM, Sara Kim wrote:
> Hi,
> I'm using a USRP205mini-i. I followed the YouTube tutorial online on how to 
> build a FM receiver. I execute the flow graph, and all I hear is very choppy 
> and high pitched audio coming from my computer's speaker (i see aUaUaU and an 
> occasional O. I know this has to to with the input/output frequency being to 
> fast/slow). I can make out the radio station I'm tuned in, but not very 
> clearly. When listening to the .wav file produced, it sounds perfectly 
> normal. I did change the audio sink sample rate to 48kHz and the wave file 
> sink to 68kHz instead of keeping it at the original in the tutorial. Any 
> suggestions or ideas as to how to fix this?
> 
> -- 
> Sara Kim 
> University of Maryland, Class of 2020
> A. James Clark School of Engineering, B.S Electrical Engineering
> 443-745-9890 | skim0131@umd. edu
> linkedin: https://www.linkedin.com/in/sarakim31/
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Help with sound output

[Sara Kim]

Hi,
I'm using a USRP205mini-i. I followed the YouTube tutorial online on how to
build a FM receiver. I execute the flow graph, and all I hear is very
choppy and high pitched audio coming from my computer's speaker (i see
aUaUaU and an occasional O. I know this has to to with the input/output
frequency being to fast/slow). I can make out the radio station I'm tuned
in, but not very clearly. When listening to the .wav file produced, it
sounds perfectly normal. I did change the audio sink sample rate to 48kHz
and the wave file sink to 68kHz instead of keeping it at the original in
the tutorial. Any suggestions or ideas as to how to fix this?

-- 
Sara Kim
University of Maryland, Class of 2020
A. James Clark School of Engineering, B.S Electrical Engineering
443-745-9890 | skim0131@umd. edu
linkedin: https://www.linkedin.com/in/sarakim31/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] test message please ignore

[Marcus Müller]

Eamon,

please don't do this; there's more than 3000 email addresses on this
mailing list. If you have any problems with your subscription, feel
free to mail discuss-gnuradio-requ...@gnu.org with "help" in the
subject line.

A much better way to get to know whether the mailing list works would
be by sending a self-introduction email and check the mailing list
archives for it an hour later, if you're not sure it reached the list.

Best regards,
Marcus

On Thu, 2019-06-06 at 09:39 -0400, Eamon Heaney wrote:
> Another test message, due to my subscription wonkiness. Thank you for
> bearing with me.
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] test message please ignore

[Eamon Heaney]

Another test message, due to my subscription wonkiness. Thank you for
bearing with me.

-- 
Eamon Heaney
*Fleet Commander*
*President, Model UN at Virginia Tech*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Getting a Runtime Error: gr::tuntap_pdu::make: tun_alloc failed

[Heaney, Eamon]

Trying to run a modified version of the wifi transceiver from this repo:
https://github.com/bastibl/gr-ieee802-11

Swapped out the USRP source for Osmocom (HackRF), and the USRP sink for a
null sink. When I try to run it, I get this error:


Traceback (most recent call last):
  File
"/home/galloway/working/seniordesign/gnuradio-companion/wifi_transceiver.py",
line 343, in 
main()
  File
"/home/galloway/working/seniordesign/gnuradio-companion/wifi_transceiver.py",
line 331, in main
tb = top_block_cls()
  File
"/home/galloway/working/seniordesign/gnuradio-companion/wifi_transceiver.py",
line 236, in __init__
self.blocks_tuntap_pdu_0 = blocks.tuntap_pdu('tap1', 440, False)
  File
"/usr/lib64/python2.7/site-packages/gnuradio/blocks/blocks_swig6.py", line
1046, in make
return _blocks_swig6.tuntap_pdu_make(dev, MTU, istunflag)
RuntimeError: gr::tuntap_pdu::make: tun_alloc failed (are you running as
root?)



I am most assuredly *not* running as root, and I'm unsure what
"gr::tuntap_pdu::make" or "tun_alloc" are. There was one similar email
chain (https://marc.info/?l=gnuradio-discuss&m=141563926501407&w=2) from a
few years ago, but the solution he found doesn't seem to work; changing
TUNTAP PDU doesn't fix the problem.

Anyone have a clue as to why these tuntap pdu things are acting up?

-- 
_The information contained in this communication may be subject to legal 
confidentiality protection or privilege. It is intended solely for use by 
the intended recipient and others authorized to receive it. If you have 
received this communication in error, please notify the sender and delete 
it immediately. You are hereby notified that any disclosure, copying, 
distribution or taking action in reliance of the contents of this 
information is strictly prohibited and may be unlawful.  The school accepts 
no liability whatsoever for any damage, loss, or expense arising from any 
misuse of this e-mail and/or from the accessing of any files attached to 
this e-mail._
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Test message please ignore

[Heaney, Eamon]

Been having subscription issues, checking to see if I can mail the list.

-- 
_The information contained in this communication may be subject to legal 
confidentiality protection or privilege. It is intended solely for use by 
the intended recipient and others authorized to receive it. If you have 
received this communication in error, please notify the sender and delete 
it immediately. You are hereby notified that any disclosure, copying, 
distribution or taking action in reliance of the contents of this 
information is strictly prohibited and may be unlawful.  The school accepts 
no liability whatsoever for any damage, loss, or expense arising from any 
misuse of this e-mail and/or from the accessing of any files attached to 
this e-mail._
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Getting a Runtime Error: gr::tuntap_pdu::make: tun_alloc failed

[Eamon Heaney]

Tried sending this last night, but it didn't seem to go through.

Trying to run a modified version of the wifi transceiver from this repo:
https://github.com/bastibl/gr-ieee802-11

Swapped out the USRP source for Osmocom (HackRF), and the USRP sink for a
null sink. When I try to run it, I get this error:


Traceback (most recent call last):
  File
"/home/galloway/working/seniordesign/gnuradio-companion/wifi_transceiver.py",
line 343, in 
main()
  File
"/home/galloway/working/seniordesign/gnuradio-companion/wifi_transceiver.py",
line 331, in main
tb = top_block_cls()
  File
"/home/galloway/working/seniordesign/gnuradio-companion/wifi_transceiver.py",
line 236, in __init__
self.blocks_tuntap_pdu_0 = blocks.tuntap_pdu('tap1', 440, False)
  File
"/usr/lib64/python2.7/site-packages/gnuradio/blocks/blocks_swig6.py", line
1046, in make
return _blocks_swig6.tuntap_pdu_make(dev, MTU, istunflag)
RuntimeError: gr::tuntap_pdu::make: tun_alloc failed (are you running as
root?)



I am most assuredly *not* running as root, and I'm unsure what
"gr::tuntap_pdu::make" or "tun_alloc" are. There was one similar email
chain (https://marc.info/?l=gnuradio-discuss&m=141563926501407&w=2) from a
few years ago, but the solution he found doesn't seem to work; changing
TUNTAP PDU doesn't fix the problem.

Anyone have a clue as to why these tuntap pdu things are acting up?


-- 
Eamon Heaney
*Fleet Commander*
*President, Model UN at Virginia Tech*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Request for comment: FFT optimizations

[CEL]

Hi Albin,

no, it's not been discussed on the list, as far as my memory reaches.
We're talking about gr:fft:fft_vcc, right?

Because that output memory shifting only happens when you set shift = 1
in the constructor. I don't have any hard feelings about whether to
shift the output or perform an exp(j π n) frequency shift (a.k.a.
multiplying with +1 -1 …). My gut feeling is that copying blocks of
memory is probably significantly faster than accessing all elements of
said blocks through the CPU sequentially. Memcpy implementations are
heavily hand-assembler optimized!

However, the actual FFT would access these elements most definitely,
so, for amounts of input samples smaller than the available CPU cache,
the +1 -1 variant would act like an elegant prefetcher and probably be
a bit more efficient, but for sizes larger, it would probably even
thrash the caches a bit and mean one additional loop over all data.
So, honestly, in many cases I'd expect a small improvement, in some a
performance degradation. Not quite sure whether looking into that is
clever. 

I'd however say that it should be obvious to do the +1 -1 input
multiplication instead of the memcpy output shift if a window is
applied, because the +1 -1 can be absorbed into the window in that
case. (Watch out for the odd-length corner case where you get two
different windows depending on whether you do an odd- or an even-
numbered transform.)

There's another easy way we can optimize things at nearly zero cost:

The memcpy to the FFTW input buffer only happens so that data is
properly aligned for FFTW to be able to use SIMD. Obviously, that copy
could be avoided alltogether if the input *is* already aligned.

FFTW does have a fftwf_alignment_of() that you can use to compare the
alignment of the especially aligned fftw plan input buffer, and the
current workload input pointer.
Same applies to the output buffer of the fftw plan and the output
pointer.

If the input buffer and the work input pointer, and the output buffer
and the work output pointer, are of the same aligment, one could simply
use fftwf_execute_dft(plan, *in, *out) instead of fftwf_execute(plan),
and not memcpy anything (unless the user requests shifting).

Chances are that, considering our circular buffers are page-aligned,
and that fft_length mod 4 = 0, for most applications,

fft_length * sizeof(gr_complex_float) = (fft_length/4) * 4 * 64 

are typically already 256-byte aligned, and things are "inherently
good". 


Cheers,
Marcus

On Thu, 2019-06-06 at 11:13 +0200, Albin Stigö wrote:
> Hi,
> 
> There's a lot of memcpy/memmove going on in the FFT kernel which I
> suspect degrades performance quite a bit... This is partly because
> some platforms requires buffers to be aligned for SIMD to work and
> partly because DC is not normally centered (which is normally what you
> would like to see in a spektrum).
> 
> For ARM in particular the alignment requirements are less strict so
> that would get rid of at least one memcpy for that platform.
> 
> For centering an FFT at DC there's a nice trick, you just rotate the
> input by pi, that is multiply by 1, -1, 1, -1... I suspect that would
> be quite a bit faster than two memcpy and should be available on all
> platforms.
> 
> Has this been discussed on the list before?
> 
> 
> --Albin
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Request for comment: FFT optimizations

[Albin Stigö]

Hi,

There's a lot of memcpy/memmove going on in the FFT kernel which I
suspect degrades performance quite a bit... This is partly because
some platforms requires buffers to be aligned for SIMD to work and
partly because DC is not normally centered (which is normally what you
would like to see in a spektrum).

For ARM in particular the alignment requirements are less strict so
that would get rid of at least one memcpy for that platform.

For centering an FFT at DC there's a nice trick, you just rotate the
input by pi, that is multiply by 1, -1, 1, -1... I suspect that would
be quite a bit faster than two memcpy and should be available on all
platforms.

Has this been discussed on the list before?


--Albin

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio