RE: Serial connection between multiple pannerNodes recursively

Dear All.

I would like to summarize this issue to clear what we need to discuss.

#Discussion point
How does it behave if there are multiple pannerNodes in AudioContext.
A pannerNodes is existed for panning and spatialization effects for Web
Audio API.
In specification, there are mainly several values for effects.
(DopplerShift, distanceEffect, Sound Cones and Panning)

How it should work that all elements for these kinds of effects should be
affect to output sound of AudioContext.

In addition, we can't find any restriction about number of pannerNode that
JS developer can create in specification.
This flexibility gives a variety which is able to connect multiple of
pannerNode in AudioContext freely.

EX)
Source1 -> Panner1 ->
			    Panner3 -> Destination
Source2 -> Panner2 ->


var context = new AudioContext();
var source1 = context.createBufferSource();
var source2 = context.createBufferSource();
var panner1 = context.createPanner();
var panner2 = context.createPanner();
var panner3 = context.createPanner();
var listener = context.listener;

listener.setPosition(1.0, 2.5, 3.0);
listener.dopplerFactor = 1.2;
listener.speedOfSound = 343.3;

panner1.setPosition(1.0,1.0,1.0);
panner2.setPosition(1.0,2.0,1.0);
panner3.setPosition(1.0,1.0,2.0);

source1.connect(panner1);
source2.connect(panner2);
panner1.connect(panner3);
panner2.connect(panner3);
panner3.connect(context.destination);

source1.start(0);
source2.start(1);


#Questions
1. Multiple pannerNodes in serial.
(SourceNode1) -> (PannerNode1) -> (PannerNode3) -> (Destination)

PannerNode1's position and PannerNode3's position affect to SourceNode1 ?
Or Only one of them, it should be affected? PannerNode1's position? Or
PannerNode3's position?

If the pannerNode must be one in AudioContext, it doesn't need to be
connectable Node.
I think that it can be inside AudioContext such as AudioListner and
AudioDestinationNode.

Ex)
If there are 2 speaker(sourceNode) and one human listener(AudioContext's
listener) in the room.
2 speakers can move their position continuously during playing a music with
different speed.
A human listener also can move postion. Each sourceNode should be able to be
affected dopplerRate and distance, cone Effect independently.


Please refer previous mail from HongChan Choi<choihongchan@gmail.com> ,
>> The serial connection of two different panner nodes is not that unusual.
>> Actually, it is quite common in the music production software.
>> For example, you can create a mix group with multiple audio streams
(which has individual pan position)
>> and you can control the stereo position of the whole mix group with the
last panner node.
>> So being able to create a serial connection with multiple panners should
be possible or even essential, I guess.


Please refer previous mail from Karl Tomlinson
<karlt+public-audio@karlt.net>
>> One source can only play back at one rate (unless the source and all
other nodes in common paths are cloned).
>>
>> This is a problem when there are multiple panners downstream from a
source, whether they are in parallel or serial.
>> Even if they are in serial, it wouldn't make sense to just sum the
Doppler effects
>> because the velocity of each panner is relative to the listener, not
directly to any up- or down-stream panner.
>>
>> One way to do this right is with delay buffers.  Each delay buffer can be
controlled precisely through
>> the AudioParam interface, and apply the correct effect for each path in
the graph.
>> This is effective for any kind of source upstream.
>>
>> Delay buffers may be costly on memory use if the object is 1 km away.
>> playbackRate is available as an alternative on AudioBufferSourceNode and
frequency on Oscillator, with AudioParam interfaces for continuously varying
values.
>>
>> As the Web Audio API has delay nodes, and playbackRate, there is no need
for a Doppler effect on PannerNode.
>> I wonder whether PannerNode.setVelocity() is ideal anyway because the
desired effect would usually be a transition through time,
>> but the setVelocity method only accepts constant values at each call.



2. Multiple pannerNodes in parallel with multiple AudioBufferSourceNodes.
(Source1) -> (Panner1) ->
			        Destination
(Source2) -> (Panner2) ->

Panner1 should affect to only Source1 ?
Panner2 should affect to only Source2 ?
One of pannerNode should affect to both Sources ? If it is, which one ?

3. OscilatorNode and ScriptProcessNode.
There can be also SourceNode. Should those nodes be affected?


#Appendix.
Please share current implementation of webkit and Mozilla.

Case.
Source1 -> Panner1 ->
			    Panner3 -> Destination
Source2 -> Panner2 ->

< blink / webkit >
Panner1's dopplerRate is affected to Source1.
Panner2's dopplerRate is affected to Source2.
Panner1 and Panner3's distanceConeGain is affected to Source1.
Panner2 and Panner3's distanceConeGain is affected to Source2.

< Gecko >
Pleas add someone Gecko current.


Please feel free anyone to give opinion. Welcome to discuss.



Br,
Khno


-----Original Message-----
From: Karl Tomlinson [mailto:karlt+public-audio@karlt.net] 
Sent: Saturday, March 01, 2014 5:20 PM
To: keonho07.kim@samsung.com
Cc: rtoy@google.com; cwilso@google.com; choihongchan@gmail.com;
public-audio@w3.org
Subject: Re: Serial connection between multiple pannerNodes recursively

KeonHo Kim writes:

> I don't know also why other source type is not considered. The others 
> should be affected.
>
> Also, I think that all doppler rates from connected panners should 
> affect audio sources when they adjust source's playback rate.

One source can only play back at one rate (unless the source and all other
nodes in common paths are cloned).

This is a problem when there are multiple panners downstream from a source,
whether they are in parallel or serial.  Even if they are in serial, it
wouldn't make sense to just sum the Doppler effects because the velocity of
each panner is relative to the listener, not directly to any up- or
down-stream panner.

One way to do this right is with delay buffers.  Each delay buffer can be
controlled precisely through the AudioParam interface, and apply the correct
effect for each path in the graph.  This is effective for any kind of source
upstream.

Delay buffers may be costly on memory use if the object is 1 km away.
playbackRate is available as an alternative on AudioBufferSourceNode and
frequency on Oscillator, with AudioParam interfaces for continuously varying
values.

As the Web Audio API has delay nodes, and playbackRate, there is no need for
a Doppler effect on PannerNode.  I wonder whether
PannerNode.setVelocity() is ideal anyway because the desired effect would
usually be a transition through time, but the setVelocity method only
accepts constant values at each call.

Received on Tuesday, 11 March 2014 08:19:25 UTC