I am building an app that converts text messages to speech and sends them to the destination. At the other end, the speech is converted back to text messages.
I imagine it may be easy with Twilio but I don't want to use internet connection. A simple call should be enough to transmit the data.
Any idea on how I should proceed with this?
I don't think this is really possible to do, your tasks would be pretty heavy ...
TTS- that's no problem android has a library for that TTS and recording it
Make a phone call and monitor state Make phone call monitor state
Send your synthesized message - can't quite find a way to do this, seems problematic sending recorded messages over phone network it has been suggested that you could play the recording over the speaker and the microphone might pick that up, seems like a good way to introduce even more errors into the system though
On the other end something must answer - Answering a phone call
Record incoming call - this seems to be highly problematic on a non-rooted phone Recording incoming calls? or Recording incoming calls
Take the recording and do reliable STT without the benefit of a server back end, also highly problematic since the translation errors even on high end server apps are sometimes quite comical
So without a rooted phone with a custom rom I don't think all of this is possible even if you could overcome the poor quality of a double translation TTS -> STT
Twillo seems to be about making calls over the net vs. the phones digital network not about sending text (in essence) over a phone connection
Seems like a whole lot of extra work just to avoid an internet connection charge (of about 2 seconds and few bytes!)
Related
I'm working on an app to cipher the audio stream sent via a voice call. Not VoIP call, just regular GSM phone call.
I have put together all of the core Android code classes to recreate the whole process of making a phone call but I always hit a dead spot where I can follow no longer.
Essentially, what need to know is: Where does Android manager the data that is being sent through a phone call. I mean were the bytes sent are.
Thanks ahead.
In very (over..) simple terms an Android phones consists of a general purpose processor which runs the Android OS and is similar to a regular 'computer' and dedicated hardware including a 'baseband' processor that handles the Mobile Phone communications.
The interface between the Android world and the GSM/UMTS phone world is tightly defined and the Android side has only limited access to the 'phone' side. This is for security and reliability reasons - e.g. it avoids a 'bad' app being able to take the phone down, which could have very serious consequences in emergency call situations.
The normal interface into the telephony side from Android is:
http://developer.android.com/reference/android/telephony/TelephonyManager.html
I am trying to determine if it is possible to use an incoming call to trigger an Android enabled phone to record video for a particular number of seconds and then send the resulting video file to an e-mail address. Sort of like having remote control camera functionality that is activated by an incoming call. (No particular model of phone or version of Android. I'm first just trying to determine if this is even possible.)
Here is a scenario to help understand how I am trying to apply this:
Two phones are involved, Phone A & Phone B.
Phone A is secured to pole with the camera viewfinder facing it's subject in New York.
Phone B is 3,000 miles away in Portland, Oregon.
Phone B calls phone A.
On receiving the phone call (or any phone call), Phone A automatically begins recording 10 seconds of video, then sends the resulting video file to an outside e-mail address.
All of this is done using the regular telephone cellular network, not wi-Fi
I hope I am clear eneough. You don't have to answer in great length. At this point I'm mainly interested in simply knowing if this is possible, and if so, what level of difficulty and possible limitations might exist depending on things like type of Android phone.
I really appreciate your feedback.
I don't see why it wouldn't work. I think you can have a broadcast receiver for incoming calls and then it's a matter to start video recording and then send the video to your email.
All this can be done, it's a matter of putting it together ;)
I'm currently working on an android project and I am trying to find the best way to go about setting up communication between two android phones.
One android phone will be docked on a mobile platform e.g. an R/C car. I want this phone to receive simple control signals ("forward", "backward", "left", "right", "gotoCoordinate") sent from another android phone. I also want the docked phone to be able to return status signals.
Preferably I want the communication to happen via GPRS. I'm aware of the difficulties concerning P2P-communications and I'm currently looking into "Android Cloud To Device Messaging." (http://code.google.com/android/c2dm/index.html)
I'd like to hear about your experience with Android C2DM (glad to hear about delay from transmit to receive) and your thoughts on utilizing it in my project. I'd appreciate other suggestions on how to go about this. I'm expecting to have to deal with relatively high latency using this method, but of course preferably lowest possible.
C2DM makes no guarantee about the "delivery or order" of the messages, and it is limited in the number of messages you can send (a high limit, but still a limit). It's not really for low-latency stuff like controlling an RC car. It's better for non-realtime events.
http://code.google.com/android/c2dm/
For lower latency stuff using GPRS you can setup a third party server on your own and have both phones communicate through it. I've done that for several Android apps using straight up TCP sockets and it works reasonably well (and it would be even faster/better if you went UDP). Using GPRS may still have too much latency, depending on your needs, but it's a tradeoff (it's very convenient, almost always there, other methods are not).
The ideal way to do this would be to combine whatever is available and fallback gracefully, and test the latency once connected to make sure the network is up to par, or bail out. For example, use the local WiFi network if it's available. That is to say, have both devices "register" with a third party server as they startup, then if they're both on the same WiFi just have them communicate directly (run a server on or both, and clients on one or both, get information about discovery and such from the registration). If they are not on WiFi then fall back to GPRS, but realize there will be more latency, of course. Finally, once any method has been established send some test messages to check latency.
I know this isn't really an "answer," it's more of a stream of consciousness about this, but it wouldn't fit in a comment, and I thought it might help ;).
(Full disclosure: I've worked on Android apps that connect multiple mobile devices and multiple TVs, some over GPRS, some Wifi, some directly. I work for a company (MOVL) that makes a platform for stuff like that, it's more focused on mobile-TV-mobile, but it supports mobile-mobile also. In all it's not too hard to do yourself with regular networking, the tricky part is getting the latency down and picking the correct method for each device.)
I'm currently creating an Android App where it collects data through bluetooth and draw a real time graph but it seems like after short while there is packet loss and graph comes out weird. I've been searching for a while how to recover the loss but seems like there is no way.... only TCP/IP or UDP has.... Since I need all the data, I can't ignore the packets that doesn't have starting bit or end bit. Is there anyway to prevent the loss or recover the loss completely?
Thanks
Use of RFComm on Android already has built in packet order and reliability like TCP. You should try running tests to see if the Android device is too far away, receiving accurate information, has a bad Bluetooth module, or if the sensor is at fault.
I require a fast reliable method of sending control commands (simple data, possibly only a few dozen possible commands) to a remote system which is using a smartphone* as its onboard computer. I have deemed standard data packages used for mobile internet data transfer as too unreliable of control purposes, however I have noticed that once a voice call is initiated it is much more reliable. Has there been any development into sending data between phones across a connected call, and if not are there any known reasons a modified dialup modem in software form couldn't be used?
Furthermore, could this protocol be robust enough to send back low res video and other simple numeric data?
*Smartphone - A phone with significant processing power and ability to run custom programs (most likely with an Android based OS however am open to suggestions)
Have you tried SMS? while you won't get video data it may work for small chunks of data. Also if the small chunks are from the phone to a server, you may try sending DTMF down the line (however I've yet to see that working.
Other than that it's customised hardware.
Hmmm...this reminds me of those old TV games like Hugo...there you had a voice connection and I think the commands were given by the different tone of the key pressed from 0-9. Maybe you should try something similar.