WFS 3D driving function for virtual line source

[trettberg]

The current formulation of the line source driving function is used for 2D and 3D WFS, but it only works in 2D. To make it work, I think x0 - xs should be replaced with a vector perpendicular to the line source, that is x0 - xs - <x0-xs,v> v where xs is a point on the line and v a unit vector along the line.

[hagenw]

I think this corresponds to #54, where we discussed a line source for the case of 3D NFC-HOA and we should maybe solve this in the same way?

For the NFC-HOA case we have two possible solutions at the moment:

1) use a normal xs vector with a length of 3. Ignore the z-entry of that vector (or do a projection onto the xy-plane) and always place the line source perpendicular to the xy-plane.

2) use a xs vector as in the case of a focused source, which has a length of 6 and contains the direction of the line source beside its position.

I think solution 2 would be preferrable, but I haven't checked how easy the implementation will be. For NFC-HOA, @narahahn stated: " I think the driving functions can be obtained by applying a rotational operation on the sphere."

[narahahn]

I also noticed this problem (in 3D WFS) while preparing the AES paper. Since I was considering only vertically aligned line sources, I just replaced xs(3) with x0(3) for each driving function so that the propagation distance (and delay) is computed correctly.

For NFC-HOA, we could rotate the coordinate system in such a way that the line source is aligned parallel to the z-axis (as @fietew mentioned). Then we can obtain the driving function in a simpler way. In WFS, however, rotating the coordinate system would be not necessary, and the WFS driving functions can be directly computed as Till proposed.

[trettberg]

The NFC-HOA case (#54) was the very reason to look into this. Maybe we continue the discussion over there. (I think agreement about xs is the hardest part of fixing the WFS case.)

[hagenw]

Yes, I agree this will be solved at #54.