Closed pizqleh closed 3 years ago
Thanks for bringing this up.
The given code example is not straightforwardly working with radius not equal 1, since the grid sizes then get different and thus subtracting of these arrays is not working. In general, for finding bugs it is a good idea to choose rather odd numbers for parameters. Multiplication with 1 might mask certain important details.
Anyway, your actual problem seems to be the following: since the sum G @ d_hoa
operation should approximate the SFS integral, we need to include weights of the SSD. In your case of circular array we need the arc length between two speakers
ssd_weight = radius * 2*np.pi/n_loud
which then should be included in G @ d_hoa * ssd_weight
. If we have not regular sampling of the SSD, we obviously need to deal with an array of weights. This is always stored in an sfs generated array.a
. The synthesize()
then handles this weighting, see ssd.a
-> a
p = 0
for x, n, a, d, weight in zip(ssd.x, ssd.n, ssd.a, d, weights):
if weight != 0:
p += a * weight * d * secondary_source_function(x, n, **kwargs)
In a manual version this should be implemented as well. Then the sound fields should match.
I see.. this fully explains the phenomena. Thank you very much!
Describe the problem/bug Apparently, the driving function given by _wfs.point25d and _nfchoa.point25d is not consistent with the common normalization of the point source model for the loudspeakers. It seems that it has an extra factor of n_loudspeakers / (2 pi radius).
To Reproduce
Expected behavior One can see that there is no problem with the point source case. However, in HOA and WFS, there is a multiplying factor between the sound fields generated manually (multiplying the driving function by the G transfer function) and the sound fields generated by fd.synthesize. I think that this should not happen, because in both cases the driving function was the same: the one given by _wfs.point25d or _nfchoa.point25d. Moreover, the ratio between the sound fields should be 1, but it is 7.957747154594, which is an approximation to n_loud / (2 pi radius). (In the example radius = 1 and _nloud=50, but one can try examples varying the radius and the number of loudspeakers to see the trend).
It's wierd, because the sound field given by fd.synthesize is actually the correct one (is the one that ressembles the point source case), and the sound field generated manually is too large (7.9577 times). But we are generating the sound field manually under the common point source mode. So one can infere that is in the driving function where there is an extra factor of (n_loud / (2 pi radius)) that actually is then compensated inside fd.synthesize by an other factor of 2 pi radius/ n_loud.
It's something wrong in this analysis? Thank you in advance,
Pedro Izquierdo L.