RE: Serial connection between multiple pannerNodes recursively

I have left comment on https://github.com/WebAudio/web-audio-api/issues/298
Also test cases has been attached on
https://code.google.com/p/chromium/issues/detail?id=349325.

Please refer those samples.

-----Original Message-----
From: Olivier Thereaux [mailto:olivier.thereaux@bbc.co.uk] 
Sent: Monday, March 31, 2014 11:12 PM
To: KeonHo Kim
Cc: Audio WG
Subject: Re: Serial connection between multiple pannerNodes recursively

Hi KeonHo,

Many thanks for your summary of the issue.

All - please note that the summary has also been added to our issues list on
Github:
https://github.com/WebAudio/web-audio-api/issues/298

KeonHo - would you be able to add a test case (or at least, at this point in
time, example code) for the two cases you use in your summary report?

There was also a suggestion to share the current interpretation/behaviour of
each implementation. A good next step IMHO.

Best,
Olivier


On 11 Mar 2014, at 08:18, KeonHo Kim <keonho07.kim@samsung.com> wrote:

> 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.
>
>

--
Olivier Thereaux - BBC Internet Research and Future Services






-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal
views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
-----------------------------

Received on Tuesday, 1 April 2014 12:26:44 UTC