For Steven or anyone else working with WebAssembly in AudioWorklets,
my issue https://github.com/gogins/csound-extended/issues/18 may be
useful. It is about a demo program at
https://github.com/madChopsCoderAu/WASMAudio that instantiates a
WebAssembly module in an AudioWorkletProcessor without jumping through
hoops. At the bottom of the issue are the numerous steps that I had to
take to get this thing to build and run, but it does run.

Regards,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com

I've been working on AudioWorklet the past few days have it working in
the worklet branch:

https://github.com/csound/csound/tree/worklet

The CsoundObj implementation runs on AudioWorklet is available but
falls back to ScriptProcessorNode otherwise.

I've been doing a lot of testing to try to get this all working and
it's not simple. I'm currently testing across Chrome 66 and Firefox on
Windows 10, and Chrome 65, Chrome 66 (Beta) and Firefox on Android.

I've found AudioWorklet so far to perform with more audio breakups
than ScriptNodeProcessor.  I'm in the middle of testing various things
and have a few more things to test before it's available to release.
One thing that is a showstopper though is that AudioWorklet doesn't
seem to work with ServiceWorker (i.e, Progressive Web Apps) and I'm
inquiring about that now.

I'll report back when this work is completely, hopefully in the next
couple days.



On Sun, Apr 22, 2018 at 1:14 PM, Michael Gogins
 wrote:
> For Steven or anyone else working with WebAssembly in AudioWorklets,
> my issue https://github.com/gogins/csound-extended/issues/18 may be
> useful. It is about a demo program at
> https://github.com/madChopsCoderAu/WASMAudio that instantiates a
> WebAssembly module in an AudioWorkletProcessor without jumping through
> hoops. At the bottom of the issue are the numerous steps that I had to
> take to get this thing to build and run, but it does run.
>
> Regards,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com

Thanks for the information. I've been following your work.

If there are more breakups with AudioWorklet than with
ScriptNodeProcessor, is this something you can iron out, or do you
think that is just the way it is?  If so, I don't see why the
ScriptNodeProcessor implementation should be replaced.

Regards,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Sun, Apr 22, 2018 at 5:24 PM, Steven Yi  wrote:
> I've been working on AudioWorklet the past few days have it working in
> the worklet branch:
>
> https://github.com/csound/csound/tree/worklet
>
> The CsoundObj implementation runs on AudioWorklet is available but
> falls back to ScriptProcessorNode otherwise.
>
> I've been doing a lot of testing to try to get this all working and
> it's not simple. I'm currently testing across Chrome 66 and Firefox on
> Windows 10, and Chrome 65, Chrome 66 (Beta) and Firefox on Android.
>
> I've found AudioWorklet so far to perform with more audio breakups
> than ScriptNodeProcessor.  I'm in the middle of testing various things
> and have a few more things to test before it's available to release.
> One thing that is a showstopper though is that AudioWorklet doesn't
> seem to work with ServiceWorker (i.e, Progressive Web Apps) and I'm
> inquiring about that now.
>
> I'll report back when this work is completely, hopefully in the next
> couple days.
>
>
>
> On Sun, Apr 22, 2018 at 1:14 PM, Michael Gogins
>  wrote:
>> For Steven or anyone else working with WebAssembly in AudioWorklets,
>> my issue https://github.com/gogins/csound-extended/issues/18 may be
>> useful. It is about a demo program at
>> https://github.com/madChopsCoderAu/WASMAudio that instantiates a
>> WebAssembly module in an AudioWorkletProcessor without jumping through
>> hoops. At the bottom of the issue are the numerous steps that I had to
>> take to get this thing to build and run, but it does run.
>>
>> Regards,
>> Mike
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com

Not sure what's going on yet.  The goal is to be better performing and
I would guess in cases where it is not it is a bug.  I saw this just
now:

https://bugs.chromium.org/p/chromium/issues/detail?id=825823&q=audioworklet&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified

Which seems not good.  Then again, webaudiomodules runs pretty well
here on Chrome 66 with limited testing.




On Sun, Apr 22, 2018 at 5:56 PM, Michael Gogins
 wrote:
> Thanks for the information. I've been following your work.
>
> If there are more breakups with AudioWorklet than with
> ScriptNodeProcessor, is this something you can iron out, or do you
> think that is just the way it is?  If so, I don't see why the
> ScriptNodeProcessor implementation should be replaced.
>
> Regards,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Sun, Apr 22, 2018 at 5:24 PM, Steven Yi  wrote:
>> I've been working on AudioWorklet the past few days have it working in
>> the worklet branch:
>>
>> https://github.com/csound/csound/tree/worklet
>>
>> The CsoundObj implementation runs on AudioWorklet is available but
>> falls back to ScriptProcessorNode otherwise.
>>
>> I've been doing a lot of testing to try to get this all working and
>> it's not simple. I'm currently testing across Chrome 66 and Firefox on
>> Windows 10, and Chrome 65, Chrome 66 (Beta) and Firefox on Android.
>>
>> I've found AudioWorklet so far to perform with more audio breakups
>> than ScriptNodeProcessor.  I'm in the middle of testing various things
>> and have a few more things to test before it's available to release.
>> One thing that is a showstopper though is that AudioWorklet doesn't
>> seem to work with ServiceWorker (i.e, Progressive Web Apps) and I'm
>> inquiring about that now.
>>
>> I'll report back when this work is completely, hopefully in the next
>> couple days.
>>
>>
>>
>> On Sun, Apr 22, 2018 at 1:14 PM, Michael Gogins
>>  wrote:
>>> For Steven or anyone else working with WebAssembly in AudioWorklets,
>>> my issue https://github.com/gogins/csound-extended/issues/18 may be
>>> useful. It is about a demo program at
>>> https://github.com/madChopsCoderAu/WASMAudio that instantiates a
>>> WebAssembly module in an AudioWorkletProcessor without jumping through
>>> hoops. At the bottom of the issue are the numerous steps that I had to
>>> take to get this thing to build and run, but it does run.
>>>
>>> Regards,
>>> Mike
>>>
>>> -----------------------------------------------------
>>> Michael Gogins
>>> Irreducible Productions
>>> http://michaelgogins.tumblr.com

Reading this issue, it's not clear to me that indeed it is a real
issue, the very end of the issue log is hard to understand.

Are you still using base64 to get the WebAudio code into the processor
thread? Did you try to post the module to the thread using the message
port?

Regards,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Sun, Apr 22, 2018 at 7:08 PM, Steven Yi  wrote:
> Not sure what's going on yet.  The goal is to be better performing and
> I would guess in cases where it is not it is a bug.  I saw this just
> now:
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=825823&q=audioworklet&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified
>
> Which seems not good.  Then again, webaudiomodules runs pretty well
> here on Chrome 66 with limited testing.
>
>
>
>
> On Sun, Apr 22, 2018 at 5:56 PM, Michael Gogins
>  wrote:
>> Thanks for the information. I've been following your work.
>>
>> If there are more breakups with AudioWorklet than with
>> ScriptNodeProcessor, is this something you can iron out, or do you
>> think that is just the way it is?  If so, I don't see why the
>> ScriptNodeProcessor implementation should be replaced.
>>
>> Regards,
>> Mike
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Sun, Apr 22, 2018 at 5:24 PM, Steven Yi  wrote:
>>> I've been working on AudioWorklet the past few days have it working in
>>> the worklet branch:
>>>
>>> https://github.com/csound/csound/tree/worklet
>>>
>>> The CsoundObj implementation runs on AudioWorklet is available but
>>> falls back to ScriptProcessorNode otherwise.
>>>
>>> I've been doing a lot of testing to try to get this all working and
>>> it's not simple. I'm currently testing across Chrome 66 and Firefox on
>>> Windows 10, and Chrome 65, Chrome 66 (Beta) and Firefox on Android.
>>>
>>> I've found AudioWorklet so far to perform with more audio breakups
>>> than ScriptNodeProcessor.  I'm in the middle of testing various things
>>> and have a few more things to test before it's available to release.
>>> One thing that is a showstopper though is that AudioWorklet doesn't
>>> seem to work with ServiceWorker (i.e, Progressive Web Apps) and I'm
>>> inquiring about that now.
>>>
>>> I'll report back when this work is completely, hopefully in the next
>>> couple days.
>>>
>>>
>>>
>>> On Sun, Apr 22, 2018 at 1:14 PM, Michael Gogins
>>>  wrote:
>>>> For Steven or anyone else working with WebAssembly in AudioWorklets,
>>>> my issue https://github.com/gogins/csound-extended/issues/18 may be
>>>> useful. It is about a demo program at
>>>> https://github.com/madChopsCoderAu/WASMAudio that instantiates a
>>>> WebAssembly module in an AudioWorkletProcessor without jumping through
>>>> hoops. At the bottom of the issue are the numerous steps that I had to
>>>> take to get this thing to build and run, but it does run.
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>> -----------------------------------------------------
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://michaelgogins.tumblr.com

Yes, still using base64 at the moment. It's been low priority on my
list to deal with how the bytes get there as long as we had a way to
get it there.  There's a separate issue here regarding transfer:

https://bugs.chromium.org/p/chromium/issues/detail?id=808848&can=2&start=0&num=100&q=&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort=

But, if I read it right, it is targeted for Chrome 67, so I figured
better to wait.

Good news from this morning is that Victor helped to fix up two issues
and the performance is much, much better now (quite good really!).
Turns out Csound was trying to write to disk even though we had some
other settings set, and I think other examples had -odac in their code
whereas the test code I had happened to not have that (as I'm using
just ORC code and not CSDs).  Anyways, mood is now optimistic.  Still
some further testing and demos to write but should be able to report
back later today or tomorrow.



On Sun, Apr 22, 2018 at 8:47 PM, Michael Gogins
 wrote:
> Reading this issue, it's not clear to me that indeed it is a real
> issue, the very end of the issue log is hard to understand.
>
> Are you still using base64 to get the WebAudio code into the processor
> thread? Did you try to post the module to the thread using the message
> port?
>
> Regards,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Sun, Apr 22, 2018 at 7:08 PM, Steven Yi  wrote:
>> Not sure what's going on yet.  The goal is to be better performing and
>> I would guess in cases where it is not it is a bug.  I saw this just
>> now:
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=825823&q=audioworklet&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified
>>
>> Which seems not good.  Then again, webaudiomodules runs pretty well
>> here on Chrome 66 with limited testing.
>>
>>
>>
>>
>> On Sun, Apr 22, 2018 at 5:56 PM, Michael Gogins
>>  wrote:
>>> Thanks for the information. I've been following your work.
>>>
>>> If there are more breakups with AudioWorklet than with
>>> ScriptNodeProcessor, is this something you can iron out, or do you
>>> think that is just the way it is?  If so, I don't see why the
>>> ScriptNodeProcessor implementation should be replaced.
>>>
>>> Regards,
>>> Mike
>>>
>>> -----------------------------------------------------
>>> Michael Gogins
>>> Irreducible Productions
>>> http://michaelgogins.tumblr.com
>>> Michael dot Gogins at gmail dot com
>>>
>>>
>>> On Sun, Apr 22, 2018 at 5:24 PM, Steven Yi  wrote:
>>>> I've been working on AudioWorklet the past few days have it working in
>>>> the worklet branch:
>>>>
>>>> https://github.com/csound/csound/tree/worklet
>>>>
>>>> The CsoundObj implementation runs on AudioWorklet is available but
>>>> falls back to ScriptProcessorNode otherwise.
>>>>
>>>> I've been doing a lot of testing to try to get this all working and
>>>> it's not simple. I'm currently testing across Chrome 66 and Firefox on
>>>> Windows 10, and Chrome 65, Chrome 66 (Beta) and Firefox on Android.
>>>>
>>>> I've found AudioWorklet so far to perform with more audio breakups
>>>> than ScriptNodeProcessor.  I'm in the middle of testing various things
>>>> and have a few more things to test before it's available to release.
>>>> One thing that is a showstopper though is that AudioWorklet doesn't
>>>> seem to work with ServiceWorker (i.e, Progressive Web Apps) and I'm
>>>> inquiring about that now.
>>>>
>>>> I'll report back when this work is completely, hopefully in the next
>>>> couple days.
>>>>
>>>>
>>>>
>>>> On Sun, Apr 22, 2018 at 1:14 PM, Michael Gogins
>>>>  wrote:
>>>>> For Steven or anyone else working with WebAssembly in AudioWorklets,
>>>>> my issue https://github.com/gogins/csound-extended/issues/18 may be
>>>>> useful. It is about a demo program at
>>>>> https://github.com/madChopsCoderAu/WASMAudio that instantiates a
>>>>> WebAssembly module in an AudioWorkletProcessor without jumping through
>>>>> hoops. At the bottom of the issue are the numerous steps that I had to
>>>>> take to get this thing to build and run, but it does run.
>>>>>
>>>>> Regards,
>>>>> Mike
>>>>>
>>>>> -----------------------------------------------------
>>>>> Michael Gogins
>>>>> Irreducible Productions
>>>>> http://michaelgogins.tumblr.com

It's kind of a configuration issue in need to set -odac. It could be
controlled by end user by using setOption() (I had that in some but
not all of my test projects), but better to force it in CsoundObj.
Seems that using API setHostImplementedIO didn't affect things if
-odac wasn't there.

On Mon, Apr 23, 2018 at 8:21 AM, Michael Gogins
 wrote:
> Do you mean CsoundObj was trying to write to disk, or libcsound64.a?
>
> On Mon, Apr 23, 2018, 07:44 Steven Yi  wrote:
>>
>> Yes, still using base64 at the moment. It's been low priority on my
>> list to deal with how the bytes get there as long as we had a way to
>> get it there.  There's a separate issue here regarding transfer:
>>
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=808848&can=2&start=0&num=100&q=&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort=
>>
>> But, if I read it right, it is targeted for Chrome 67, so I figured
>> better to wait.
>>
>> Good news from this morning is that Victor helped to fix up two issues
>> and the performance is much, much better now (quite good really!).
>> Turns out Csound was trying to write to disk even though we had some
>> other settings set, and I think other examples had -odac in their code
>> whereas the test code I had happened to not have that (as I'm using
>> just ORC code and not CSDs).  Anyways, mood is now optimistic.  Still
>> some further testing and demos to write but should be able to report
>> back later today or tomorrow.
>>
>>
>>
>> On Sun, Apr 22, 2018 at 8:47 PM, Michael Gogins
>>  wrote:
>> > Reading this issue, it's not clear to me that indeed it is a real
>> > issue, the very end of the issue log is hard to understand.
>> >
>> > Are you still using base64 to get the WebAudio code into the processor
>> > thread? Did you try to post the module to the thread using the message
>> > port?
>> >
>> > Regards,
>> > Mike
>> >
>> > -----------------------------------------------------
>> > Michael Gogins
>> > Irreducible Productions
>> > http://michaelgogins.tumblr.com
>> > Michael dot Gogins at gmail dot com
>> >
>> >
>> > On Sun, Apr 22, 2018 at 7:08 PM, Steven Yi  wrote:
>> >> Not sure what's going on yet.  The goal is to be better performing and
>> >> I would guess in cases where it is not it is a bug.  I saw this just
>> >> now:
>> >>
>> >>
>> >> https://bugs.chromium.org/p/chromium/issues/detail?id=825823&q=audioworklet&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified
>> >>
>> >> Which seems not good.  Then again, webaudiomodules runs pretty well
>> >> here on Chrome 66 with limited testing.
>> >>
>> >>
>> >>
>> >>
>> >> On Sun, Apr 22, 2018 at 5:56 PM, Michael Gogins
>> >>  wrote:
>> >>> Thanks for the information. I've been following your work.
>> >>>
>> >>> If there are more breakups with AudioWorklet than with
>> >>> ScriptNodeProcessor, is this something you can iron out, or do you
>> >>> think that is just the way it is?  If so, I don't see why the
>> >>> ScriptNodeProcessor implementation should be replaced.
>> >>>
>> >>> Regards,
>> >>> Mike
>> >>>
>> >>> -----------------------------------------------------
>> >>> Michael Gogins
>> >>> Irreducible Productions
>> >>> http://michaelgogins.tumblr.com
>> >>> Michael dot Gogins at gmail dot com
>> >>>
>> >>>
>> >>> On Sun, Apr 22, 2018 at 5:24 PM, Steven Yi  wrote:
>> >>>> I've been working on AudioWorklet the past few days have it working
>> >>>> in
>> >>>> the worklet branch:
>> >>>>
>> >>>> https://github.com/csound/csound/tree/worklet
>> >>>>
>> >>>> The CsoundObj implementation runs on AudioWorklet is available but
>> >>>> falls back to ScriptProcessorNode otherwise.
>> >>>>
>> >>>> I've been doing a lot of testing to try to get this all working and
>> >>>> it's not simple. I'm currently testing across Chrome 66 and Firefox
>> >>>> on
>> >>>> Windows 10, and Chrome 65, Chrome 66 (Beta) and Firefox on Android.
>> >>>>
>> >>>> I've found AudioWorklet so far to perform with more audio breakups
>> >>>> than ScriptNodeProcessor.  I'm in the middle of testing various
>> >>>> things
>> >>>> and have a few more things to test before it's available to release.
>> >>>> One thing that is a showstopper though is that AudioWorklet doesn't
>> >>>> seem to work with ServiceWorker (i.e, Progressive Web Apps) and I'm
>> >>>> inquiring about that now.
>> >>>>
>> >>>> I'll report back when this work is completely, hopefully in the next
>> >>>> couple days.
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Sun, Apr 22, 2018 at 1:14 PM, Michael Gogins
>> >>>>  wrote:
>> >>>>> For Steven or anyone else working with WebAssembly in AudioWorklets,
>> >>>>> my issue https://github.com/gogins/csound-extended/issues/18 may be
>> >>>>> useful. It is about a demo program at
>> >>>>> https://github.com/madChopsCoderAu/WASMAudio that instantiates a
>> >>>>> WebAssembly module in an AudioWorkletProcessor without jumping
>> >>>>> through
>> >>>>> hoops. At the bottom of the issue are the numerous steps that I had
>> >>>>> to
>> >>>>> take to get this thing to build and run, but it does run.
>> >>>>>
>> >>>>> Regards,
>> >>>>> Mike
>> >>>>>
>> >>>>> -----------------------------------------------------
>> >>>>> Michael Gogins
>> >>>>> Irreducible Productions
>> >>>>> http://michaelgogins.tumblr.com