0

I am having to do floating point maths on arrays of ints, fast and with low latency for audio apps (multi channel). My code works but I wonder if theres more efficient ways of processing in places. I get buffers of around 120 frames of interleaved 32 bit audio integers of 16 or 24 channels, which I then have to convert to arrays of floats / doubles for processing (eg biquad filters). Currently I iterate through the arrays and cast each integer to an element of a float array. Then I process these and cast them back to ints for the write buffer, which I pass back to the lib function (I'm on linux using snd_pcm_readi and snd_pcm_writei). Theres lots of copying and it seems wasteful.

The quicker I can do it the lower my latency so the better the overall performance as its for live sound use.

I have read about SSE and other extensions which can be compiled in with gcc options, and some references allude to being able to pass arrays for streamlined conversion etc, and I wonder if these might help the above. Or maybe I should not bother casting to floats - change my processing functions to use ints, keep track of overflows, maybe use 64 bit ints instead, and or create a separate array for exponent - seems pretty esoteric to me, but I guess its not that hard to implement and only needs to be coded once etc. I have asked a separate question of 'Is FPM required for audio DSP maths, or can it be done in 32/64 bit integer maths before rounding back to 24 bits for output?' which is part of the same topic but I thought I should split it into a different question.

Pete
  • 335
  • 1
  • 3
  • 12
  • 2
    What about if you post your code ? so developers can try to highlight where your `code` can be improved ?? – mlwn Sep 08 '14 at 13:39
  • 1
    This similar question may prove useful: http://stackoverflow.com/questions/429632/how-to-speed-up-floating-point-to-integer-number-conversion – John Hascall Sep 08 '14 at 13:45
  • Hmm yes it did prove useful, thanks. I guess as mlwn said I should post code but the current code is far too spread around, I will have to write a example snippet to do this. Having read the other question and thought about the complexity for a while I think I will stick with what I am doing and come back to this (if anyone posts significant information in the meantime then all the better). Its clear that the conversion is very expensive and that if I can eliminate floating point entirely and work in integers I will benefit, but I will have to implement psuedo fp myself in that case. Thx all. – Pete Sep 09 '14 at 10:27
  • If you are going to be doing that sort of filtering with integers, you should consider using [Fixed Point Arithmetic](http://en.wikipedia.org/wiki/Q_(number_format)). Skype has an example in their codec that has freely available [reference code](http://tools.ietf.org/html/draft-vos-silk-01). Just search the page for biquad. – Degustaf Sep 09 '14 at 12:42
  • Degustaf, very interesting thanks. Good to see someone doing it and I will check out the example. – Pete Sep 10 '14 at 09:55

1 Answers1

0

If your code is license-compatible, you can use the Vector optimized library of kernels (VOLK) from the GNU Radio project, which has a kernel that does that conversion

32i_s32f_convert_32

converts the input 32 bit integer data into floating point data, and divides the each floating point output data point by the scalar value

It comes with heavily optimized implementations for SSE2, aligned and unaligned data.

EDIT: By the way, why not just do your signal processing in GNU Radio itself?

Marcus Müller
  • 34,677
  • 4
  • 53
  • 94