Process callback advice

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Process callback advice

ajg112
Hi All,

I'm implementing a microphone array beamforming application. I have 8
capture ports and a single playback port (thanks to Paul Davis for his
help getting this working).

The beamforming processing basically requires implementing a set of FIR
filters (about 75-100 taps each) for each input channel.

I'm wondering if its considered 'bad-practice' to put this sort of
computation into the Jack process callback or whether I should implement
some ring buffers (1 interleaved input, 1 output) and a separate
beamforming computation thread.

This question is probably quite academic as I'm sure the actual amount
of computation would be completed in a sufficiently short time, but I'm
interested if anyone has any thoughts.

Thanks
Andy

--
Dr. Andrew Greensted      Department of Electronics
Audio Lab                 University of York, YO10 5DD, UK

Tel: +44(0)1904 432828    Mailto: [hidden email]
Fax: +44(0)1904 432335    Web: http://www.labbookpages.co.uk
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Process callback advice

Paul Davis
On Wed, Sep 22, 2010 at 11:26 AM, Andy Greensted <[hidden email]> wrote:

> Hi All,
>
> I'm implementing a microphone array beamforming application. I have 8
> capture ports and a single playback port (thanks to Paul Davis for his help
> getting this working).
>
> The beamforming processing basically requires implementing a set of FIR
> filters (about 75-100 taps each) for each input channel.
>
> I'm wondering if its considered 'bad-practice' to put this sort of
> computation into the Jack process callback or whether I should implement
> some ring buffers (1 interleaved input, 1 output) and a separate beamforming
> computation thread.
>
> This question is probably quite academic as I'm sure the actual amount of
> computation would be completed in a sufficiently short time, but I'm
> interested if anyone has any thoughts.

if it doesn't have to do any blocking operations (i.e. its just math)
then its ENTIRELY appropriate for it to be called directly from (or be
within) the process callback.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Process callback advice

torbenh
In reply to this post by ajg112
On Wed, Sep 22, 2010 at 04:26:58PM +0100, Andy Greensted wrote:

> Hi All,
>
> I'm implementing a microphone array beamforming application. I have
> 8 capture ports and a single playback port (thanks to Paul Davis for
> his help getting this working).
>
> The beamforming processing basically requires implementing a set of
> FIR filters (about 75-100 taps each) for each input channel.
>
> I'm wondering if its considered 'bad-practice' to put this sort of
> computation into the Jack process callback or whether I should
> implement some ring buffers (1 interleaved input, 1 output) and a
> separate beamforming computation thread.

it would be bad practise to separate it into some other thread.
(except if your doing a fast convolution, and the jack blocksize is
smaller than your fft size)

separate threads are for things which might block.
 - reading stuff from files
 - allocating memory etc..

if the filter needs more cpu time than is available, it wont work in
realtime anyways... a separate thread is pretty likely to make you hit
this point quicker.

(i am still assuming your doing the stuff in timedomain)

in case you dont really change your taps, you might want to look at
jconvolver. it does a proper fast convolution, and doesnt eat your cpu.

although i guess a modern cpu can do 8*100 tap convolution easily in
timedomain.



>
> This question is probably quite academic as I'm sure the actual
> amount of computation would be completed in a sufficiently short
> time, but I'm interested if anyone has any thoughts.


>
> Thanks
> Andy
>
> --
> Dr. Andrew Greensted      Department of Electronics
> Audio Lab                 University of York, YO10 5DD, UK
>
> Tel: +44(0)1904 432828    Mailto: [hidden email]
> Fax: +44(0)1904 432335    Web: http://www.labbookpages.co.uk
> _______________________________________________
> Jack-Devel mailing list
> [hidden email]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

--
torben Hohn
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Process callback advice

Fons Adriaensen-2
In reply to this post by Paul Davis
On Wed, Sep 22, 2010 at 11:31:55AM -0400, Paul Davis wrote:

> On Wed, Sep 22, 2010 at 11:26 AM, Andy Greensted <[hidden email]> wrote:
> > Hi All,
> >
> > I'm implementing a microphone array beamforming application. I have 8
> > capture ports and a single playback port (thanks to Paul Davis for his help
> > getting this working).
> >
> > The beamforming processing basically requires implementing a set of FIR
> > filters (about 75-100 taps each) for each input channel.
> >
> > I'm wondering if its considered 'bad-practice' to put this sort of
> > computation into the Jack process callback or whether I should implement
> > some ring buffers (1 interleaved input, 1 output) and a separate beamforming
> > computation thread.
> >
> > This question is probably quite academic as I'm sure the actual amount of
> > computation would be completed in a sufficiently short time, but I'm
> > interested if anyone has any thoughts.
>
> if it doesn't have to do any blocking operations (i.e. its just math)
> then its ENTIRELY appropriate for it to be called directly from (or be
> within) the process callback.

Yes. There are some practical limits of course. You wouldn't want to
call a 16 Kpoint FFT from a callback using a period size of 256 samples
for example.

For the application you described you could have a look at jconvolver.
It's a general-purpose convolution engine, and it was actually developed
originally to do beamforming. It will do any convolution matrix up to
64 by 64 (if your CPU can handle it), and will optimise sparse matrices
in all three dimensions: inputs, outputs, and time. Documentation is
lacking ATM, but if you would be using it for research feel free to
interrupt me.

Ciao,

--
FA

There are three of them, and Alleline.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Process callback advice

ajg112
Many thanks all for your feedback. I've now got a better feel for how to
use JACK.

Andy

--
Dr. Andrew Greensted      Department of Electronic
Audio Lab                 University of York, YO10 5DD, UK

Tel: +44(0)1904 432828    Mailto: [hidden email]
Fax: +44(0)1904 432335    Web: http://www.labbookpages.co.uk
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org