You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
As of this writing, the audio bytes are read into Urbit as
cord
s. 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.The text was updated successfully, but these errors were encountered: