如何使用libwebsocket将16bit音频数据发送到服务器

Question

I want to send the audio data to server using libwebsocket.

audio data is 16bits, 16Khz format.

But ws_service_callback on the server side is like below:

static int ws_service_callback(
                         struct lws *wsi,
                         enum lws_callback_reasons reason, void *user,
                         *void *in*, size_t len)

Here ws_service_callback is the callback function of server when server receives something from client side.

*void *in* is the data from client side, and it is 8 bit format. (here 8 bit and 16 bit mitmatch)

Should the client side split the audio data to two 8 bits, then send it to the server side??

Then the server side needs to sum the two 8bit to one 16bit?

Answer 1

Usually the 16b audio data are stored in memory as continuous block of bits (and also bytes then), so whether you treat them as 16b or 8b doesn't matter during transmission of the whole block (or save/load to disc, etc). Ie 1234 16b values can be treated as 2468 8b values in this context the network layer doesn't need to care.

But then processing the data on the server side, when it will treat the two consecutive 8 bit values as single 16b value, needs to know how the original data should be treated, because there are two common ways (and infinite amount of uncommon/custom including things like compressed data or specifically designed order of bits, delta encoding, etc... none of that supported by the CPU on single machine instruction level, ie these need implementation in the code), little-endian vs big-endian (one of these is for sure supported in "native" way by the CPU, some CPUs even support both and can be switched at boot time).

For example Intel CPUs are "little-endian", so when you write 16b value 0x1234 into memory in the "native" way, it will occupy two bytes in this order: 0x34, 0x12 (lower 8 bits are stored first, then higher 8 bits), or 32b value 0x12345678 is stored as four bytes 78 56 34 12 .

On big-endian platforms the order is opposite, so high-order bytes are stored first, and 32b value 0x12345678 is stored (in CPU "native" way) as four bytes 12 34 56 78 .

As you can see, two platforms talking through network layer, must be aware of the endian-ness of each, and convert such data to interpret them correctly.

As you are basically designing binary network protocol for this service, you should define what is the expected order of the bits. If both client and server are expected to be of particular platform, for best performance a simplest implementation you can define the protocol to follow the native way of those plaftorms. Then if you will implement this protocol on platform which has different native way, you will have to add conversion of the data before sending it to server. (or if you expect the clients to be low-power devices and server to have abundance of power, you can define protocol which supports both common ways by having some flag, and do the conversion on server side for the "other" one).