Skip to content
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

Audio should be signed ints or bytes #2

Open
nick1udwig opened this issue Nov 7, 2021 · 0 comments
Open

Audio should be signed ints or bytes #2

nick1udwig opened this issue Nov 7, 2021 · 0 comments

Comments

@nick1udwig
Copy link
Owner

As of this writing, the audio bytes are read into Urbit as cords. This is because there aren't library functions for parsing JSON into signed integers, and so (list cord) was the path of least resistance.

However, this is less than ideal for two reasons.

First, it would be nice to check that audio int16s are within bounds. Currently, the golang middleman is able to clip one int16 per audio send (other samples that are out of bounds will be set to 0), and so a misbehaving client may lead to suboptimal results. Really, it should be the audio sender's job to ensure audio is valid, but we should also handle misbehaving clients well.

Second: data efficiency! An int16 is two bytes; if it costs more than two bytes per sample to send, we are burning bandwidth, and Urbit is not the fastest networking-wise, so this actually becomes quite important.

The first of these points argues for reading into @sd; the second for reading into bytes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant