Is it possible to build an app which allows for full duplex audio conferencing? Is there one out there I haven't found yet?
I work in a theatre and our comm system is failing. Everyone has smartphones so it would be easy to utilize these as comm systems. We use a full-duplex system with a talk button.
You don't even need an app. WebRTC will suffice.
There are some off-the-shelf libraries that wrap everything up for you very nicely:
RTC.io - http://rtc.io/
PeerJS - http://peerjs.com/
Since you'll be using headsets, I recommend disabling echo cancellation as you won't need it and it only hurts sound quality.
Related
In a client to client situation I would use Chrome's navigator APIs to get a MediaStream and add its tracks to my RTCPeerConnection.
But I would prefer not opening a chrome window on my raspberry Pi to do this.
Are there any easy-to-use bindings in python or node JS to get a MediaStream and send it to a WebRTC peer?
If you only want to use webrtc without your own customization, you can try uv4l or rpi-webrtc-streamer. They provide webrtc solution with built in signalling over websockets.
If you want to use webrtc but your own signalling, you can do proxy over inbuilt signalling. Other solutions like AIORTC or Node PeerConnection or node-webrtc May not be that much easy to use/configure.
My approach would rather be the chrome driver which can be run headless (mainly used for automated UI testing). You can start the browser by the command-line and give it some arguments like --headles and more. Pretty sure there are some nice libraries within python to do so. But maybe that's a wrong approach here.
So there is a similar question already asked, where different approaches where suggested.
If you want a Python implementation of WebRTC, give aiortc a try. It features support for audio, video and data channels and builds upon Python's asyncio framework.
But maybe check out the answers there, hope it helps!
Sounds like Alohacam will do what you're looking for. Uses WebRTC to provide a real-time stream from your Raspberry Pi camera to any web browser (Chrome, Firefox, Safari, Opera, Edge, iOS, and Android). Also includes TURN support (no need to bring your own TURN relay). If you don't mind a closed-source solution that "just works", it may help. (full disclosure: I'm one of the authors -- would love to hear how it works out for you).
We are currently in the middle of a large infrastructure rebuild. We are replacing everything from the CRM to the ERP to the CTI.
We have decided to use WebRTC for the CTI. After working with WebRTC for a bit I really see the promise in this technology and started to think that maybe this is the way we want to go for our Webchat as well.
The premise behind this is to be able to add Voice / Video and Screensharing to our chat feature at some point in time.
Since WebRTC is not supported in Safari IE Edge Etc. I am thinking we may be just slightly ahead of ourselves in using WebRTC for text chat.
One thought would be to build it all out as WebRTC determine if the browser allows as default back to XMPP etc.
I have been researching this on my own and have found some options out there like talky.io but in this rebuild we are focusing on not having any third parties involved in our applications (We have had a couple go bye bye with no warning).
Is there a framework / library / open source project out there that tackles part or all of this task?
Is this task as daunting as I think it is going to be or am I overreacting?
Am I crazy, should be locked in a padded room and use an existing chat service?
talky is built ontop of https://github.com/legastero/stanza.io which includes a jingle/webrtc module
Take a look at the Jitsi project (specifically Jitsi Meet). A public version is running at meet.jit.si that you can try out; it uses webrtc for the voice / video, and Jingle / XMPP for the signaling. It is all open source, so you can be sure you won't lose access if the company goes under or something else bad were to happen. The Jitsi team runs it using the Prosody XMPP server; they make a good combination.
I need to develop an app where several ipads communicate to a single main iPad. Would this be done using Bonjour or Game Kit? I looked at Bluetooth but that seems like a 1 to 1 communication. I have never messed with either of these API's
You could use Bonjour to do this -- but remember that Bonjour is only a framework to advertise services and doesn't do any of the actual connection itself.
For Bonjour, you need to create an NSNetServicesBrowser to scan the network (which can use Bluetooth -- or WiFi) and publish an NTNetService with the port for the other iPads to connect to (this could be the "master" iPad itself).
Then you would need to run a server on the "master" iPad (that is advertising the service) and then have some sockets code to handle all of that. (For which I recommend AsyncSocket (http://code.google.com/p/cocoaasyncsocket/).
Let me know if this is something you would be interested in doing, and I would be able to provide some code snippets as a starting point...
Like Glycerin said earlier, take a look at WebSockets. You can choose to have one-to-one, one-to-many, many-to-many connections, and is insanely fast.
Here's a tutorial on Nettuts
WebSockets are the way to go. I would suggest learning about the basics of sockets, there are implementation in most programming languages. This helped me a lot: http://beej.us/guide/bgnet/ After getting a understanding of what sockets are and what they do u could use the CocoaAsyncSocket-Framework http://code.google.com/p/cocoaasyncsocket/ on iOS. It adds an additional level of abstraction to sockets that helps especially with non-blocking network communication. There is some sample code available.
I see that Game Kit allows you to develop games with voice chat.
I want to build a more general, peer-to-peer voice chat application, that does not have to live in the Game Center. So a couple questions:
1. What peer to peer system/technologies could be used for this?
2. If I wanted to allow voice chat with a Flash client (i.e. iPhone app <--> Server <---> Flash client on PC) would options for 1 work for this?
I have some experience with RTFMP for Flash to Flash client chat, and no iPhone dev experience, so just want to test out some ideas.
Maybe one idea: build using the Ribbit Platform - they have both Objective-C and Flash SDKs, but this looks more like traditional\SIP calling.
Anyway, would appreciate anything that points me in the right direction.
Thanks.
Now that flash has access to raw Microphone data, you could roll your own client and server; yet, since, currently, it doesn't have UDP sockets in AIR for mobile, you would be forced into considering audio quality vs lagg with even tighter restrictions then usual.
You can now roll your own native extension to make this work; yet, I am assuming you want something that only requires coding in AS3.
Therefore, considering your restrictions, the only real bet would be to use Flash's built-in communications capabilities (e.g. RTMP).
With the above being said, there are opensource alternatives to the array of Adobe's own flash communication servers:
the red5 server, and rtmpd.
IMHO Ribbit's services are kind of pointless.
I'm planning on building an application where audio media is going to be streamed to the mobile phone for the user to listen.
The targets are smartphones: iPhone/Blackberry/Android/(J2ME ?).
I see that streaming on iPhone has to be done with HTTP Live streaming, but I don't see it supported by other platforms.
Should I broadcast the streams via rstp ? http ? Is there any way to use a unified solution for all the different mobile platform ? If anyone already had to go through this, help would be greatly appreciated.
One answer to the question "what technology to use ?", for iPhone specifically is WiFi. I know that's not the type of question you are asking, but its a point worth making! Many apps that support streaming over 3G have been rejected by Apple due to bandwidth usage. You may need to be prepared to sense network connection type and limit streaming to when you have a WiFi connection only.
Blackberry works with http and RSTP on OS 4.3 or later. I'm not familiar with other platforms but I would think http would be the most compatible.
Here is a PDF that lists the supported types by the major models.
http://docs.blackberry.com/en/smartphone_users/deliverables/15801/711-01774-123_Supported_Media_Types_on_BlackBerry_Smartphones.pdf
You will probably want to do RTSP, but it doesn't really matter. HTTP Live Streaming is just a protocol on the client side I am pretty sure. All these acronyms just describe ways of transmitting data. If a browser can access the data for a given protocol....chances are a phone can too. It sounds like you are asking more of a server side question.....but that question is the least of your worries You are going to have to think more along the lines of "How am I going to scale this" rather than "What protocol should I use to transmit data". Also, the unified solution for all clients, would be to have a server that they all hit for data. You still need to develop separate clients for each OS.
Both Android and BlackBerry supports RTSP.
Note that some BlackBerry devices only support 15fps video, so you may need separated streams to give the best experience to your users.
iPhone, starting from iPhone OS 3.0, needs HTTP Live Streaming.
The only software solution I know to support all above is Wowza, but you still need an encoder. (I think Wowza supports RTP as input, but need double checking.)
iPhone can play non-streamed audio (progressive download). Considered all platforms you would normally you just needs streams that are suitable transcoded. See f.e. https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/Introduction/Introduction.html The title says its about 'HTTP Live Streaming' but a lot applies for just downloading and playing streams.