NFC-HOA orders for time-domain driving functions

[narahahn]

Unlike for monochromatic cases, it seems that the Ambisonic order cannot be freely chosen for time-domain NFC-HOA driving function. It only works if the order is an integer multiple of the number of secondary sources, of vice versa. I started to implement for arbitrary integer orders. Would it be worth doing this?

[hagenw]

That is another good point. It would be a very good idea as we would have a big problem otherwise.
A few comments:

1. I have fixed a small error, see e170daa and 78e2b5d
2. As we have corrected the behavior of nfchoa_order() -- see 422b4f9 -- it will not return not a multiple of the secondary sources for band-limited NFC-HOA. For example:

>> conf = SFS_config;
>> sound_field_imp_nfchoa([-2 2],[-2 2],0,[0 -1 0],'pw',300,conf)
Error using driving_function_imp_nfchoa (line 157)
DRIVING_FUNCTION_IMP_NFCHOA: the given number of secondary sources (64) cannot be subsampled to 62 driving signals. Choose a NFC-HOA order that is a multiple of 30.

Error in sound_field_imp_nfchoa (line 94)
d = driving_function_imp_nfchoa(x0,xs,src,conf);

As you can see the numbers in the error message are now also broken, but the more important thing is that for band-limited NFC-HOA we cannot met the desired multiple condition. We have 64 secondary sources, which corresponds to an order of 31 (instead of 32 as it was before we corrected nfchoa_order()) which will not work with 64 secondary sources.

If you have an idea how to fix this, it would be great if you could push a new branch and create a pull request for this.

[narahahn]

I created a branch nfchoa_arbitraryorder. Now, the time-domain driving functions can be computed for any orders.

conf = SFS_config;
conf.secondary_sources.number = 64;
conf.driving_functions = 'default';
conf.plot.usenormalisation = false;
conf.plot.usedb = false;

x0 = secondary_source_positions(conf);
X = [-2 2];
Y = [-2 2];
Z = 0;
xs = [0,-1,0];
src = 'pw';
t = 200;
pulse = transpose(hann_window(5,5,10));

conf.nfchoa.order = [];
d = driving_function_imp_nfchoa(x0,xs,src,conf);
d = convolution(d,pulse);
sound_field_imp(X,Y,Z,x0,'ps',d,t,conf);
caxis([-1 1]/4)

conf.nfchoa.order = 8;
d = driving_function_imp_nfchoa(x0,xs,src,conf);
d = convolution(d,pulse);
sound_field_imp(X,Y,Z,x0,'ps',d,t,conf);
caxis([-1 1]/4)

conf.nfchoa.order = 200;
d = driving_function_imp_nfchoa(x0,xs,src,conf);
d = convolution(d,pulse);
sound_field_imp(X,Y,Z,x0,'ps',d,t,conf);
caxis([-1 1]/4)

In the above examples, the bilinear transform was used to convert the poles and zeros in the Laplace domain to the z-domain. When the matched z-transform is used for orders greater than 84, there are some noise-like components in the synthesized field.

conf.driving_functions = 'matchedz';
conf.nfchoa.order = 85;
d = driving_function_imp_nfchoa(x0,xs,src,conf);
d = convolution(d,pulse);
sound_field_imp(X,Y,Z,x0,'ps',d,t,conf);
caxis([-1 1]/4)

[hagenw]

Interesting, it looks a little bit similar to https://github.com/hagenw/phd-thesis/tree/master/03_sound_field_errors_and_their_perceptual_relevance/fig3_13
I will test it further, also #57, but it could happen that I will need a few days.

[narahahn]

You are right. The maximum order in you simulation (256) is also much greater than the anti-alliasing order (31), the results are supposed to be similar to mine (order of 200). In fact, the result is nearly identical even if the order is increased up to 500.

At this point, I am not sure if the simulation results are correct for very high orders (above 85). As mentioned in #57, there are some suspicious behavior in the driving functions. I think we first have to check the zeros of the spherical Hankel functions.

[hagenw]

I included your changes regarding the arbitrary orders into master and deleted the nfchoa_arbitraryorder branch. What is not included is the part coming from the nfchoa_sosfilter branch, due to the problems discussed here: #65

[hagenw]

I have looked again at the NFC-HOA simulations and the new behavior of using arbritrary orders. The interpolation we are doing now introduces some artifacts and I was wondering if this is natural and cannot be avoided or if we could change something.

Here is the result as it was before with version 2.0.0 (it uses 64 loudspeakers and uses order 32, which can be done without interpolation, by just using every second loudspeaker):

$ git checkout 2.0.0

conf = SFS_config_example;
conf.plot.usedb = 1;
sound_field_imp_nfchoa([-2 2],[-2 2],0,[0 2 0],'ps',200,conf);

And here is the result as it implemented now, which has the advantage to use arbritry orders ( it uses 64 loudspeakers and an order of 31):

$ git checkout master

conf = SFS_config;
conf.plot.usedb = 1;
sound_field_imp_nfchoa([-2 2],[-2 2],0,[0 2 0],'ps',200,conf);

[narahahn]

I think the difference comes from the relation of the number of secondary sources (nls) and the NFC-HOA order (order).

In the earlier version of driving_function_imp_nfchoa.m (before this branch), the driving function is computed for -order:order and the -order-th order (i.e. the first row of the matrix d) is discarded if the number of loudspeaker is even. The resulting matrix has the size of 2*order-by-N. The driving functions are then computed by spatial inverse Fourier transform. But this works only if order=nls/2 which is not the correct maximum order. In version 2.0.0, the function nfchoa_order.m was still incorrect and you fixed it in 422b4f9. In the current driving_function_imp_nfchoa.m, the NFC-HOA order is order=nls/2-1 for even nls if the order is not specified.

Still, the simulation result of the current version looks a bit strange, because of the small wavelets. But you get a similar result in version 2.0.0 if you slightly move the virtual source.

$ git checkout 2.0.0

sound_field_imp_nfchoa([-2 2],[-2 2],0,[0.1 2 0],'ps',200,conf);

[hagenw]

That is interesting, I never shifted the point source away from x=0 before, I guess. By the way for plane waves this does not happen in version 2.0.0.

To conclude: the new behavior is normal and not a bug as it is inherent to the implementation?

[narahahn]

I think it is normal.

By the way, in certain cases, we also get "clean" results with the current version.

conf.secondary_sources.number = 63;
conf.nfchoa.order = 31;
sound_field_imp_nfchoa([-2 2],[-2 2],0,[2,0,0],'ps',200,conf);

conf.secondary_sources.number = 63;
conf.nfchoa.order = 31;
sound_field_imp_nfchoa([-2 2],[-2 2],0,[-1,0,0],'pw',200,conf);