Re: [dev-servo] Error during compilation
Is it necessary to send any message to the GainNode?
> On Dec 6, 2018, at 11:04 AM, Manish Goregaokar wrote:
>
> Sorry, to clarify: this was a bug in the existing code, not your code.
> -Manish Goregaokar
>
>
> On Thu, Dec 6, 2018 at 11:04 AM Manish Goregaokar
> wrote:
>
>> I pushed a fix, please rebase your pull request to master to pull it in.
>>
>> Thanks,
>> -Manish Goregaokar
>>
>>
>> On Wed, Dec 5, 2018 at 10:08 PM Avanthikaa Ravichandran
>> wrote:
>>
>>> We pushed the final changes in the code and we have the same issue still.
>>> On running with backtrace, I got the following output:
>>>
>>> RUST_BACKTRACE=1 ./target/debug/constant_source
>>> thread 'AudioRenderThread' panicked at 'index 128 out of range for slice
>>> of length 0', libcore/slice/mod.rs:1932:5
>>> note: Some details are omitted, run with `RUST_BACKTRACE=full` for a
>>> verbose backtrace.
>>> stack backtrace:
>>> 0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
>>> at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
>>> 1: std::sys_common::backtrace::print
>>> at libstd/sys_common/backtrace.rs:71
>>> at libstd/sys_common/backtrace.rs:59
>>> 2: std::panicking::default_hook::{{closure}}
>>> at libstd/panicking.rs:211
>>> 3: std::panicking::default_hook
>>> at libstd/panicking.rs:227
>>> 4: std::panicking::rust_panic_with_hook
>>> at libstd/panicking.rs:477
>>> 5: std::panicking::continue_panic_fmt
>>> at libstd/panicking.rs:391
>>> 6: rust_begin_unwind
>>> at libstd/panicking.rs:326
>>> 7: core::panicking::panic_fmt
>>> at libcore/panicking.rs:77
>>> 8: core::slice::slice_index_len_fail
>>> at libcore/slice/mod.rs:1932
>>> 9: as
>>> core::slice::SliceIndex<[T]>>::index
>>> at libcore/slice/mod.rs:2097
>>> 10: core::slice:: for [T]>::index
>>> at libcore/slice/mod.rs:1914
>>> 11: as core::ops::index::Index>::index
>>> at liballoc/vec.rs:1725
>>> 12: servo_media_audio::block::Block::data_chan
>>> at audio/src/block.rs:166
>>> 13: servo_media_audio::param::Param::update
>>> at audio/src/param.rs:100
>>> 14: servo_media_audio::gain_node::GainNode::update_parameters
>>> at audio/src/gain_node.rs:34
>>> 15: >> servo_media_audio::node::AudioNodeEngine>::process
>>> at audio/src/gain_node.rs:55
>>> 16: servo_media_audio::graph::AudioGraph::process
>>> at audio/src/graph.rs:436
>>> 17: >::process
>>> at ./audio/src/render_thread.rs:226
>>> 18: >::event_loop
>>> at ./audio/src/render_thread.rs:312
>>> 19: >::start
>>> at ./audio/src/render_thread.rs:159
>>> 20: >::new::{{closure}}
>>> at ./audio/src/context.rs:137
>>> thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value:
>>> RecvError', libcore/result.rs:1009:5
>>> stack backtrace:
>>> 0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
>>> at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
>>> 1: std::sys_common::backtrace::print
>>> at libstd/sys_common/backtrace.rs:71
>>> at libstd/sys_common/backtrace.rs:59
>>> 2: std::panicking::default_hook::{{closure}}
>>> at libstd/panicking.rs:211
>>> 3: std::panicking::default_hook
>>> at libstd/panicking.rs:227
>>> 4: std::panicking::rust_panic_with_hook
>>> at libstd/panicking.rs:477
>>> 5: std::panicking::continue_panic_fmt
>>> at libstd/panicking.rs:391
>>> 6: rust_begin_unwind
>>> at libstd/panicking.rs:326
>>> 7: core::panicking::panic_fmt
>>> at libcore/panicking.rs:77
>>> 8: core::result::unwrap_failed
>>> at libcore/macros.rs:26
>>> 9: >::unwrap
>>> at libcore/result.rs:808
>>> 10: >::close
>>> at ./audio/src/macros.rs:24
>>> 11: constant_source::run_example
>>> at examples/constant_source.rs:82
>>> 12: constant_source::main
>>> at examples/constant_source.rs
Re: [dev-servo] Error during compilation
We pushed the final changes in the code and we have the same issue still. On
running with backtrace, I got the following output:
RUST_BACKTRACE=1 ./target/debug/constant_source
thread 'AudioRenderThread' panicked at 'index 128 out of range for slice of
length 0', libcore/slice/mod.rs:1932:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose
backtrace.
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: std::sys_common::backtrace::print
at libstd/sys_common/backtrace.rs:71
at libstd/sys_common/backtrace.rs:59
2: std::panicking::default_hook::{{closure}}
at libstd/panicking.rs:211
3: std::panicking::default_hook
at libstd/panicking.rs:227
4: std::panicking::rust_panic_with_hook
at libstd/panicking.rs:477
5: std::panicking::continue_panic_fmt
at libstd/panicking.rs:391
6: rust_begin_unwind
at libstd/panicking.rs:326
7: core::panicking::panic_fmt
at libcore/panicking.rs:77
8: core::slice::slice_index_len_fail
at libcore/slice/mod.rs:1932
9: as core::slice::SliceIndex<[T]>>::index
at libcore/slice/mod.rs:2097
10: core::slice:: for [T]>::index
at libcore/slice/mod.rs:1914
11: as core::ops::index::Index>::index
at liballoc/vec.rs:1725
12: servo_media_audio::block::Block::data_chan
at audio/src/block.rs:166
13: servo_media_audio::param::Param::update
at audio/src/param.rs:100
14: servo_media_audio::gain_node::GainNode::update_parameters
at audio/src/gain_node.rs:34
15: ::process
at audio/src/gain_node.rs:55
16: servo_media_audio::graph::AudioGraph::process
at audio/src/graph.rs:436
17: >::process
at ./audio/src/render_thread.rs:226
18: >::event_loop
at ./audio/src/render_thread.rs:312
19: >::start
at ./audio/src/render_thread.rs:159
20: >::new::{{closure}}
at ./audio/src/context.rs:137
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value:
RecvError', libcore/result.rs:1009:5
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: std::sys_common::backtrace::print
at libstd/sys_common/backtrace.rs:71
at libstd/sys_common/backtrace.rs:59
2: std::panicking::default_hook::{{closure}}
at libstd/panicking.rs:211
3: std::panicking::default_hook
at libstd/panicking.rs:227
4: std::panicking::rust_panic_with_hook
at libstd/panicking.rs:477
5: std::panicking::continue_panic_fmt
at libstd/panicking.rs:391
6: rust_begin_unwind
at libstd/panicking.rs:326
7: core::panicking::panic_fmt
at libcore/panicking.rs:77
8: core::result::unwrap_failed
at libcore/macros.rs:26
9: >::unwrap
at libcore/result.rs:808
10: >::close
at ./audio/src/macros.rs:24
11: constant_source::run_example
at examples/constant_source.rs:82
12: constant_source::main
at examples/constant_source.rs:88
13: std::rt::lang_start::{{closure}}
at libstd/rt.rs:74
14: std::panicking::try::do_call
at libstd/rt.rs:59
at libstd/panicking.rs:310
15: __rust_maybe_catch_panic
at libpanic_unwind/lib.rs:103
16: std::rt::lang_start_internal
at libstd/panicking.rs:289
at libstd/panic.rs:392
at libstd/rt.rs:58
17: std::rt::lang_start
at libstd/rt.rs:74
18: main
19: __libc_start_main
20: _start
The GitHub issue I referred to earlier is :
https://github.com/servo/media/pull/122
<https://github.com/servo/media/pull/122>
Please let me know what we can do to fix it. I also want to know if is it
necessary to send any message to the gain node.
Thank you
> On Nov 30, 2018, at 10:22 AM, Manish Goregaokar wrote:
>
> It would be helpful to see what your changes are and what test command
> you're running (along with a full backtrace, setting RUST_BACKTRACE=1 will
> let you get one).
>
> I'm unable to get this same error when I test your pull request locally.
> (Which github issue are you talking about?)
> -Manish Goregaokar
>
>
> On Fri, Nov 30, 2018 at 6:38 AM Avanthikaa Ravichandran
> wrote:
>
>> I made changes to the ConstantSourceNode example as suggested in the review
>> for the pull request. However, I am getting the following error while
>> running the file:
>>
>> thread 'AudioRenderThread' panicked at 'index 128 out of range for slice of
>> length 0', libcore/slice/mod.rs:1932:5
>> n
[dev-servo] Implementing periodic wave options for Oscillator node
Hi, We are implementing the periodic wave options for the oscillator node and the formula as mentioned in the link below uses a 'N' which is said to be a power of 2. How do we know what the value of N is? Is this set by the user or do we assume it to be some arbitrary power of 2 > 0? https://webaudio.github.io/web-audio-api/#dictdef-periodicwaveoptions Thank you ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Mozilla Servo Media - Implementing WebAudio Nodes
Hi, So I tried removing Copy from the OscillatorNodeOptions type but after removing it, the other files that create the context do not allow the options to be used since they need a copy to create the context object. Refer the following code: let osc1 = context.create_node(AudioNodeInit::OscillatorNode(options), Default::default()); This line throws an error for options when I remove copy. To fix this, I modified it as let osc1 = context.create_node(AudioNodeInit::OscillatorNode(options.clone()), Default::default()); However, for channelsum.rs and channel.rs, clone() is not allowed since options is created with Default::default(); Could you suggest any other solution? Thank you. On Thu, Nov 15, 2018 at 7:30 PM Manish Goregaokar wrote: > Just remove the Copy requirement on the OscillatorOptions type, it's not > necessary. > > -Manish Goregaokar > > > On Thu, Nov 15, 2018 at 4:15 PM Avanthikaa Ravichandran > > wrote: > > > Thank you so much. > > We are also trying to implement the periodic wave option for the > oscillator > > node. The sizes of the real and imag arrays in the PeriodicWaveOptions > > structure are not fixed during compile time and need to be generated > based > > on the input terms. > > For this, we thought of using a vector but the vector type does not > > implement copy. We tried to use clone() during the oscillator node object > > creation but many of the other types of waves (like channelsum) derive > the > > oscillator node and they cannot implement clone/require that copy be > > derived. Can you suggest what we can do to overcome this? Do we assume an > > outer limit to the size of the array and create an array of that size or > is > > there a way to still dynamically set the array size without the copy > > conflict? > > > > > > > > On Thu, Nov 15, 2018 at 6:16 PM Manish Goregaokar > > > wrote: > > > > > Yes, it's f(x) = k. > > > > > > Note that `k` here is an AudioParam, so it's not always a constant -- > > > similar to how frequency in OscillatorSourceNode or gain in GainNode > can > > > vary per frame. > > > -Manish Goregaokar > > > > > > > > > On Thu, Nov 15, 2018 at 2:48 PM Avanthikaa Ravichandran < > > aravi...@ncsu.edu > > > > > > > wrote: > > > > > > > Hi, > > > > > > > > We are working on implementing the missing WebAudio nodes in > > servo-media. > > > > One of the initial steps says* ‘implement the missing ConstantSource > > node > > > > type that produces a constant tone based on a stored value that can > be > > > > modified using the GainNode implementation as a model*'. > > > > > > > > Am I right in understanding that this requires implementing a wave > > f(x) = > > > > k, where k is a constant that is determined by the stored value? And > > the > > > > working of this wave is similar to sine, sawtooth, etc., with the > only > > > > difference being the wave formula? > > > > ___ > > > > dev-servo mailing list > > > > dev-servo@lists.mozilla.org > > > > https://lists.mozilla.org/listinfo/dev-servo > > > > > > > ___ > > > dev-servo mailing list > > > dev-servo@lists.mozilla.org > > > https://lists.mozilla.org/listinfo/dev-servo > > > > > ___ > > dev-servo mailing list > > dev-servo@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-servo > > > ___ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Mozilla Servo Media - Implementing WebAudio Nodes
Thank you so much. We are also trying to implement the periodic wave option for the oscillator node. The sizes of the real and imag arrays in the PeriodicWaveOptions structure are not fixed during compile time and need to be generated based on the input terms. For this, we thought of using a vector but the vector type does not implement copy. We tried to use clone() during the oscillator node object creation but many of the other types of waves (like channelsum) derive the oscillator node and they cannot implement clone/require that copy be derived. Can you suggest what we can do to overcome this? Do we assume an outer limit to the size of the array and create an array of that size or is there a way to still dynamically set the array size without the copy conflict? On Thu, Nov 15, 2018 at 6:16 PM Manish Goregaokar wrote: > Yes, it's f(x) = k. > > Note that `k` here is an AudioParam, so it's not always a constant -- > similar to how frequency in OscillatorSourceNode or gain in GainNode can > vary per frame. > -Manish Goregaokar > > > On Thu, Nov 15, 2018 at 2:48 PM Avanthikaa Ravichandran > > wrote: > > > Hi, > > > > We are working on implementing the missing WebAudio nodes in servo-media. > > One of the initial steps says* ‘implement the missing ConstantSource node > > type that produces a constant tone based on a stored value that can be > > modified using the GainNode implementation as a model*'. > > > > Am I right in understanding that this requires implementing a wave f(x) = > > k, where k is a constant that is determined by the stored value? And the > > working of this wave is similar to sine, sawtooth, etc., with the only > > difference being the wave formula? > > ___ > > dev-servo mailing list > > dev-servo@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-servo > > > ___ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] Mozilla Servo Media - Implementing WebAudio Nodes
Hi, We are working on implementing the missing WebAudio nodes in servo-media. One of the initial steps says* ‘implement the missing ConstantSource node type that produces a constant tone based on a stored value that can be modified using the GainNode implementation as a model*'. Am I right in understanding that this requires implementing a wave f(x) = k, where k is a constant that is determined by the stored value? And the working of this wave is similar to sine, sawtooth, etc., with the only difference being the wave formula? ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Rustfmt now checked on CI
We are working on the media crate for servo and we were asked to run the rustfmt to format the code. However, in the servo/media repo that we worked on, we cannot run the ./mach command. Are we expected to integrate it with the main servo repository? How do we run rustfmt on our file otherwise? Thank you On Wed, Nov 7, 2018, 2:25 PM Keith Yeung Woohoo! Great work everyone! > On Wed, Nov 7, 2018 at 11:22 AM Josh Bowman-Matthews > wrote: > > > > Thank you for all your help in formatting the existing code and enabling > > rustfmt in CI! I'm very pleased that we've adopted rustfmt and that we > > now have consistent formatting with the rest of the Rust ecosystem. > > > > Cheers, > > Josh > > > > On 11/7/18 1:51 PM, Pyfisch wrote: > > > Hi Everyone, > > > > > > Servo source code is now formatted with rustfmt [1]. Style checking is > > > part of ./mach test-tidy and enforced on CI. To automatically format > > > your code run ./mach fmt before commiting. Import order was changed but > > > ./mach fmt will fix > > > any issues. Please ask any questions you may have. > > > > > > Regards > > > Pyfisch > > > > > > [1]: https://github.com/servo/servo/pull/22126 > > > > > > > > > > ___ > > dev-servo mailing list > > dev-servo@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-servo > ___ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Query regarding WebAudio node API - Implementing periodic wave options
Thank you for your response. I was also wondering if the statement inputs.blocks.push(Default::default()); in "oscillator_node.rs" is the one setting default values for the oscillator node wave? What exactly does this statement push into the input blocks? From my understanding, this needs to be rewritten in order to implement all the possible oscillator types of the node (Sine, Sawtooth etc). Is this correct? Thank you On Wed, Nov 7, 2018 at 8:11 AM Josh Bowman-Matthews wrote: > Yes, if there are types that derive Copy right now that are being > modified in ways that forbid that (such as adding a Vec member), feel > free to remove the derivation. > > Cheers, > Josh > > On 11/6/18 8:09 PM, Avanthikaa Ravichandran wrote: > > Hi, > > I am trying to write an implementation for the PeriodicWaveOptions in the > > oscillator node. The parameters for this - real and imaginary, do not > have > > fixed sizes at compile time since they depend on the user input options. > > This requires the use of the Vec datatype. However, vectors do not derive > > copy and this means that the constructor does not have the derive. > > Correspondingly, the OscillatorNodeOptions also cannot derive copy. Does > > this mean the "derive copy" can be removed wherever necessary? If not, > what > > other datatype can be used for declaring the size at runtime? > > > > Thank you > > > ___ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > [image: Mailtrack] <https://mailtrack.io?utm_source=gmail_medium=signature_campaign=signaturevirality5;> Sender notified by Mailtrack <https://mailtrack.io?utm_source=gmail_medium=signature_campaign=signaturevirality5;> 11/07/18, 6:22:28 PM ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] Query regarding WebAudio node API - Implementing periodic wave options
Hi, I am trying to write an implementation for the PeriodicWaveOptions in the oscillator node. The parameters for this - real and imaginary, do not have fixed sizes at compile time since they depend on the user input options. This requires the use of the Vec datatype. However, vectors do not derive copy and this means that the constructor does not have the derive. Correspondingly, the OscillatorNodeOptions also cannot derive copy. Does this mean the "derive copy" can be removed wherever necessary? If not, what other datatype can be used for declaring the size at runtime? Thank you ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
