ARI ExternalMedia and slin format with 8 kHz 16 bit

[ari_segfault]

Using ARI queries, I create a bridge with two channels for Alice and Bob. After that, I create a bridge for the Snoop channel and the ExternalMedia channel. Below is a brief drawing

In my application, I receive an RTP stream and save the file. And everything works well if i create ExternalMedia channel with such POST parameters, where there is “slin16”:

{
"channelId": "EM123",
"app": "TEST_APP",
"external_host": "127.0.0.1:1234",
"encapsulation": "rtp",
"transport": "udp",
"connection_type": "client",
"format": "slin16",
"direction": "both"
}

I can save such a stream to a wav file of 16 kHz and 16 bit

But is it possible to transmit a stream of 8 kHz and 16 bit?
If I specify “slin8” when creating a channel, I get the error below::

Provided format (slin8) was not found

If I specify “slin” when creating a channel, then I will get a u-law stream 8 kHz 8 bit, but i need PCM 8 kHz 16 bit.
Of course there is a quick way to convert 16 kHz 16 bit to 8 kHz 16 bit, but I wonder why instead of PCM I get u-law

Below is more detailed information about the channel inside asterisk if I use “slin”:
asterisk -x 'core show channel UnicastRTP/127.0.0.1:1234-0x7f48b401b760

 -- General --
           Name: UnicastRTP/127.0.0.1:1234-0x7f48b401b760
           Type: UnicastRTP
       UniqueID: emedia_123
       LinkedID: snoop_123
      Caller ID: (N/A)
 Caller ID Name: (N/A)
Connected Line ID: (N/A)
Connected Line ID Name: (N/A)
Eff. Connected Line ID: (N/A)
Eff. Connected Line ID Name: (N/A)
    DNID Digits: (N/A)
       Language: en
          State: Up (6)
  NativeFormats: (ulaw)
    WriteFormat: slin
     ReadFormat: slin
 WriteTranscode: Yes (slin@8000)->(ulaw@8000)
  ReadTranscode: Yes (ulaw@8000)->(slin@8000)
 Time to Hangup: 0
   Elapsed Time: 0h0m8s
      Bridge ID: bridge_123
 --   PBX   --
        Context: default
      Extension: s
       Priority: 1
     Call Group: 0
   Pickup Group: 0
    Application: Stasis
           Data: callpy
 Call Identifer: (None)
      Variables:
BRIDGEPEER=Snoop/123
STASISSTATUS=
UNICASTRTP_LOCAL_PORT=10660
UNICASTRTP_LOCAL_ADDRESS=127.0.0.1
 -- Streams --
Name: audio-0
    Type: audio
    State: sendrecv
    Group: -1
    Formats: (ulaw)
    Metadata:

And if I use “slin16”:

 -- General --
           Name: UnicastRTP/127.0.0.1:1234-0x7f494c02f4e0
           Type: UnicastRTP
       UniqueID: emedia_123
       LinkedID: snoop_123
      Caller ID: (N/A)
 Caller ID Name: (N/A)
Connected Line ID: (N/A)
Connected Line ID Name: (N/A)
Eff. Connected Line ID: (N/A)
Eff. Connected Line ID Name: (N/A)
    DNID Digits: (N/A)
       Language: en
          State: Up (6)
  NativeFormats: (slin16)
    WriteFormat: slin16
     ReadFormat: slin16
 WriteTranscode: No 
  ReadTranscode: No 
 Time to Hangup: 0
   Elapsed Time: 0h0m7s
      Bridge ID: bridge_snoop_123
 --   PBX   --
        Context: default
      Extension: s
       Priority: 1
     Call Group: 0
   Pickup Group: 0
    Application: Stasis
           Data: callpy
 Call Identifer: (None)
      Variables:
BRIDGEPEER=Snoop/123-00000010
STASISSTATUS=
UNICASTRTP_LOCAL_PORT=10614
UNICASTRTP_LOCAL_ADDRESS=127.0.0.1
 -- Streams --
Name: audio-0
    Type: audio
    State: sendrecv
    Group: -1
    Formats: (slin16)
    Metadata:

[ldo]

It could be that PCM 8-bit is not considered worth supporting. A-law and µ-law give you improved S-N/dynamic-range anyway, that PCM can only match by going to, I dunno, 10 bits or something.

[david551]

The figure after the slin is the sample rate, not the bit width. They are all 16 bits. There isn’t an slin8 because it is the most simple case and is called slin.

[ari_segfault]

I need a sampling rate of 8 kHz PCM 16 bits. If i use slin, then the frequency is 8 kHz 8 bit u-law.
I don’t need ulaw, when I need it I can specify ulaw in the request

[david551]

slin stands for signed linear. µ-Law isn’t linear. If you are getting µ-Law it is either a bug, or it is the best available encoding to your over the wire one.