[asterisk-dev] Audio to/from Asterisk

[Seán C. McCord]

I certainly don't mind if a better-designed system comes along and obviates
my AudioSocket implementation.  I built it because I needed it.  However,
bidirectional audio flow is critical for me (speech synthesis, external
interfacing, real-time processed audio, processed injections, etc).  While
I would actually prefer a system which was a bit beefier than my own
(simple protocol aside, there's a good deal of range between my protocol
and MRCP), my meagre C skills (and patience) don't allow me to venture
forth into those difficult waters.

I do like the separate connection (unlike Wazo's) and the support of TLS
(unlike mine)... and yours is certainly (even without looking) more
performant.  Mine also probably needs a multi-threaded, dedicated-receiver
approach like most of the other channels which handle socket-received
media, rather than the simple non-blocking I/O with null frame insertion.
No perfect solution yet.



On Thu, Jul 18, 2019 at 8:01 AM George Joseph <gjoseph at digium.com> wrote:

> Hey Guys,
>
> I was on vacation when this thread happened but I'm also working on this
> now.  The implementation uses the existing ARI channel and bridge recording
> endpoints ands add the ability to specify a URI in the form of
> (udp|tcp|tls)://hostname:port to stream the media.  This makes use of the
> existing chan_bridge_media driver and only requires a scheme handler
> similar to Seán's res_audiosocket.   This implementation is more targeted
> to real-time speech recognition/transcription/captioning and is therefore
> one way (outbound).  A future enhancement is planned that would send each
> channel in a bridge as a separate audio channel in a multi-channel
> container.
>
> I'm not suggesting that this should replace Seán's audiosocket stuff but I
> did want to let you know what was in the pipeline.
>
> george
>
> On Fri, Jul 5, 2019 at 7:38 AM Seán C. McCord <ulexus at gmail.com> wrote:
>
>> Solutions such as Jack are non-network oriented and severely limited in
>> scalability.  There are, of course, many other options, but the closest are
>> chan_rtp and chan_nbs.  RTP is a good option except for the difficulty for
>> non-telephony people to interact with it.  NBS is deprecated, undocumented,
>> and unsupported by any locatable resources.
>>
>> While the original app interface from last year required dialplan, the
>> channel interface does not.  It is a plain channel which can be used by ARI
>> directly.
>>
>>
>> On Fri, Jul 5, 2019, 15:28 Sylvain Boily <sylvain at wazo.io> wrote:
>>
>>> Hello Seán,
>>>
>>> On 2019-07-05 4:45 a.m., Seán C. McCord wrote:
>>>
>>> A brief update:
>>>
>>> I have adapted my app_audiosocket from last year to become
>>> chan_audiosocket, a full bidirectional audio channel interface for Asterisk
>>> to any AudioSocket service (which itself is a dead-simple implementation).
>>> I'll be demoing it in my talk next week at CommCon, for anyone who might be
>>> interested.  I'm going to try to have it ready to push to gerrit for review
>>> this weekend.
>>>
>>>
>>> I'll be there.
>>>
>>>
>>> For now, you can see it in the 'channel' branch of
>>> github.com/CyCoreSystems/audiosocket.
>>>
>>>
>>> This is very different from what we did. You need dialplan to use it. In
>>> our case we don't need any dialplan to use it, it's more ARI approach.
>>>
>>> Sylvain
>>>
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>
>
> --
> *George Joseph*
> Digium - A Sangoma Company | Software Developer | Software Engineering
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
> direct/fax: +1 256 428 6012
> Check us out at: https://digium.com · https://sangoma.com
>
>

-- 
Seán C. McCord
ulexus at gmail.com
CyCore Systems
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20190718/d3f21416/attachment.html>