-
Notifications
You must be signed in to change notification settings - Fork 477
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Save the redundant audio worker code during build time so that the worker code stays intact and is able to be loaded #2772
Conversation
3a863b8
to
3b4e765
Compare
* This function is only meant to be called within the RED worker to initialize and start RED functionality. | ||
*/ | ||
function startRedWorker(): void { | ||
RedundantAudioEncoder.shouldLogDebug = true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be false, yes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We want the RED worker to be able to emit logs, so this should be true
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the worker have any high frequency logs? If yes, then this will lead to a lot of messages being sent from the worker to the main thread. Probably just a quick scrub of the encoder file should be good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The encoder file only has low frequency logs at the moment, so this shouldn't overload the main thread with too many messages
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we just based on the Log level defined ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated to configure this based on log level
3b4e765
to
0218702
Compare
3cb7500
to
fbd8292
Compare
config/tsconfig.red.json
Outdated
"outDir": "../build", | ||
"rootDir": "../src" | ||
}, | ||
"include": [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need a separate config for just RED? Can you put a comment in the package.json explaining it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same question. Using the existing tsconfig file I see RedundantAudioEncoder.js
being generated in the build folder? Doesn't that mean we don't need this extra tsconfig file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume this is because we need to convert ts -> js for this file first and put it in the source folder so when we transpile for the whole folder they can refer to this file
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea for generating and building the worker code was:
- Build the
RedundantAudioEncoder.js
file - Use the
RedundantAudioEncoder.js
file to generateRedundantAudioEncoderWorkerCode.ts
- Now build everything using
npm run tsc:src
so that the generatedRedundantAudioEncoderWorkerCode.ts
file also gets built and transpiled
So yes, we don't need this extra tsconfig file, but using the normal tsconfig.json
would generate all of the built files for Step 1, then the RedundantAudioEncoderWorkerCode.ts
file would be generated in Step 2, and then all of the files would be re-built again in Step 3. Having the separate config for RED was just a minor build time optimization so that we wouldn't be building all of the code twice during each npm run build
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wondering if we should make these lines INFO
rather than DEBUG
while we're at it?
[DEBUG] ChimeLogger - [AudioRed] Initializing RedundantAudioEncoder
[DEBUG] ChimeLogger - [AudioRed] Setting up sender RED transform
[DEBUG] ChimeLogger - [AudioRed] Setting up receiver RED transform
[DEBUG] ChimeLogger - [AudioRed] red payload type set to 63
[DEBUG] ChimeLogger - [AudioRed] opus payload type set to 111
* This file was generated with the `generate-red-worker-code.js` script. | ||
*/ | ||
|
||
export default class RedundantAudioEncoderWorkerCode { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Can we rename the folder to match with the file name (..workercode)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will make this change
Yes, we should make these |
fbd8292
to
57beef2
Compare
57beef2
to
c54a1fd
Compare
] | ||
} | ||
`; | ||
fs.writeFileSync(`${configDir}/${redTsconfig}`, redTsconfigContent); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure, let me add it
script/generate-red-worker-code.js
Outdated
fs.writeFileSync(`${configDir}/${redTsconfig}`, redTsconfigContent); | ||
|
||
// Transpile `RedundantAudioEncoder.ts`. | ||
const command = 'npx tsc --build config/tsconfig.red.json'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Can we not depend on npx and just use the local node_module path to tsc? otherwise you would need to update READM to install it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated to use local tsc
from node_modules
in latest push
c54a1fd
to
b442d9b
Compare
…rker code stays intact and is able to be loaded The redundant audio worker code string may vary based on the build system of different projects. Because of this, certain build systems will cause invalid worker code to be generated and the redundant audio worker will not be able to run. Now, the redundant audio worker code is saved at build time so that all clients can run the redundant audio worker with the same exact code, regardless of the client's build system. This issue was originally found in #2771.
b442d9b
to
596b50f
Compare
…rker code stays intact and is able to be loaded (#2772) The redundant audio worker code string may vary based on the build system of different projects. Because of this, certain build systems will cause invalid worker code to be generated and the redundant audio worker will not be able to run. Now, the redundant audio worker code is saved at build time so that all clients can run the redundant audio worker with the same exact code, regardless of the client's build system. This issue was originally found in #2771.
Issue #: #2771
Description of changes:
The redundant audio worker code string may vary based on the build system of different projects. Because of this, certain build systems will cause invalid worker code to be generated and the redundant audio worker will not be able to run. Now, the redundant audio worker code is saved at build time so that all clients can run the redundant audio worker with the same exact code, regardless of the client's build system.
This issue was originally found in #2771.
Testing:
Can these tested using a demo application? Please provide reproducible step-by-step instructions.
Reproduction steps for the original issue are mentioned in #2771. Following the same steps with this change should fix the issue.
Checklist:
Have you successfully run
npm run build:release
locally?y
Do you add, modify, or delete public API definitions? If yes, has that been reviewed and approved?
n
Do you change the wire protocol, e.g. the request method? If yes, has that been reviewed and approved?
n
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.