search

WebAudio / web-audio-api

The Web Audio API v1.0, developed by the W3C Audio WG
https://webaudio.github.io/web-audio-api/
Other
1.04k stars 165 forks source link

Use of AudioworkletProcessor and .port (on Chrome for Android) #2365

Closed DavideC84 closed 3 years ago

DavideC84 commented 3 years ago

Describe the issue

Hello everyone. Big thanks for this beautiful project, i'm having a blast using it.

That said, i don't know if this is a bug or i'm doing something wrong. I am using the .port feature to feed the 128 samples long output[0] array of an AudioworkletProcessor wich works as a playback source in an audio context with an 8000hz sample rate and a depth of 16-bit.

As far as i've understood from the docs and seen in the experience, the AudioworkletProcessor runs on a separate thread (the audio one).

The data is coming from the network, it gets prebuffered, decoded (Opus) and then sent to the playback audioWorklet in chunks of 128 float values. All of this, on the other side, happens on the main thread.

The design works well on Chrome/Edge desktop browsers but the same exact code fails on Chrome for Android.

I've been debugging my web app on the phone through usb debugging for days. I get no errors whatsoever, everything looks fine but the voice (it's a real time voip app) comes out robotic and distorted. Recording from the phone and streaming out to other clients (including desktop chromes) works good, despite using the same concept.

My feeling is that the AudioworkletProcessor buffer doesn't get filled "in time" because the main thread is getting behind. I can't have certainty tho. Chrome devtools doesn't even report cpu consumption in usb debugging, let alone how many ms is taking each thread.

Is that plausible to you? Any advice?

Additional Information

The web application showing this problem can be tested here: https://thecitizensband.online

padenot commented 3 years ago

This is likely a timing issue, yes. But this is unrelated to the specification.

Please file a bug at https://bugs.chromium.org/p/chromium/issues/list if you think this is appropriate, since this is either a bug in your app, or in Chrome for Android.

https://stackoverflow.com/questions/tagged/web-audio-api might also be able to help.

DavideC84 commented 3 years ago

Thanks for your reply Paul. I'll keep looking into it.

hoch commented 2 years ago

@DavideC84 Have you submitted a bug? Could you share the link to the bug?

DavideC84 commented 2 years ago

@DavideC84 Have you submitted a bug? Could you share the link to the bug?

Hello Hoch, thanks for your attention.

I didn't submit it as a bug, i'm unsure if i should consider it a bug.

I digged into it and discovered exactly what was happening, yes it was a timing issue between the main thread and the audio one. In particular, looked like the main thread was getting behind and then delivered too much data to the processor. So much data that processor was overwriting the new buffer before the end of the playing one. I needed a queue.

I solved the problem by using an internal ring buffer in the audioworkletProcessor. So now it doesn't matter if data comes every 20ms regurarly or not. I do enqueue audio chunks directly onto the audio thread.

Padenot was right. Looks like it was a flaw in my code rather than a bug.