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 Monday, 31 March 2014 14:13:00 UTC