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 <gjos...@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 <ule...@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 <sylv...@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 ule...@gmail.com CyCore Systems
-- _____________________________________________________________________ -- 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
