res_audiosocket: add message type 0x11 for slin16 audio messages

[SvenKube]

Sending audiosocket messages of type AST_AUDIOSOCKET_KIND_AUDIO_SLIN16 (0x11) creates Asterisk frames in the slin16 format, enabling the transmission of audio at a higher sample rate. For audiosocket messages sent by Asterisk, the message kind is determined by the format of the originating Asterisk frame.

UpgradeNote: A new audiosocket message type (0x11) has been added for slin16 audio. External applications using audiosocket may need to be updated to support this message type if the audiosocket channel is created with slin16 as the codec.

[SvenKube]

cherry-pick-to: 23
cherry-pick-to: 22
cherry-pick-to: 21
cherry-pick-to: 20

[github-actions]

Workflow PRCheck completed successfully

False report.

[seanbright]

It might be more flexible to include the sample rate in kHz in the message payload (1 byte should be enough?), then you could send any signed-linear data regardless of rate.

[SvenKube]

I understand the idea of including the sample rate in the payload, but I think introducing a dedicated message type for slin16 audio messages is the better approach here.

The main reasons are:

• Non-breaking change: This approach doesn’t modify the existing 0x10 packet semantics, so existing clients and libraries remain compatible.
• Protocol consistency: The audiosocket spec already defines message kinds to describe payload formats. Using a new kind for slin16 aligns with that model, whereas overloading the payload format of 0x10 would diverge from it.
• Specification accuracy: The spec currently (incorrectly) describes 0x10 as 16-bit 8 kHz signed linear data. By adding 0x11 for 16 kHz slin16, we bring the implementation in line with the documented meaning.
• Predictable parsing: Keeping the 3-byte header + payload structure untouched ensures that existing parsers continue to work as-is, without needing to introspect payload bytes to determine format.

[seanbright]

That… is a lot of AI generated text.

I’m suggesting that 0x11 have the sample rate as part of the payload. I’m not suggesting any change to 0x10.

[SvenKube]

That... is what i've written with some rewording by AI.

@seanbright To make sure I understand your suggestion correctly, which message type would you expect for 8kHz signed linear audio data? The 0x10 that would currently be sent or your proposed message containing the sample rate?

[seanbright]

8kHz would continue to be 0x10. 16kHz and up would be 0x11. You also don’t have to do anything - it was just a suggestion.

[jcolp]

I agree with @seanbright - it's going to be new, so may as well cover all the slin rates so that the next person who comes along that wants a new one doesn't have to do anything.

[seanbright]

• Specification accuracy: The spec currently (incorrectly) describes 0x10 as 16-bit 8 kHz signed linear data.

Out of curiosity, what is incorrect about the specification?

[SvenKube]

• Specification accuracy: The spec currently (incorrectly) describes 0x10 as 16-bit 8 kHz signed linear data.

Out of curiosity, what is incorrect about the specification?

The specification states that the 0x10 Packet Type contains 16-bit 8 kHz signed linear data, but when the AudioSocket channel is created with the codec slin16 the Audiosocket sends also a 0x10 packet containing 640 bytes of 16-bit 16 kHz signed linear data.

So to get 16 kHz audio data out of asterisk this "works", the receiver could determine by the payload size that the content is probably 16kHz audio. Sending 0x10 Packets with 640 bytes of 16kHz audio data on the other hand does not work as the format of the generated asterisk frame is hardcoded to slin in the module.

It seemed to me that the original specification intended for a packet type to only transport one audio format, which is where I got the idea for the new packet for 16kHz audio only.