I am trying to implement a webrtc-based video chat room and I encountered the following problem. When the call starts and my local stream goes, I listen to my audio on my device before the other device receives it. The devices are far enough apart so that the echo does not affect them. I don't know if that happens because I did something wrong or it is always like that.
I appreciate any recommendations.
Related
I want to capture live video of my Windows 7 computer, and later on have it streamed lived to a client to view as a livestream. Somewhere I heard that I could use C to make a virtual device and have the computer render the screen on that, and just output it through a socket. But, I've searched and I can't find any way to do this.
So what I'm looking for is maybe a tutorial or place to start with capturing live screen output and have it transmitted through the internet to a client that can view it live.
Any help is greatly appreciated :)
When I connect my Arduino Mega ADK board to an AOA Android app everything is fine (initially), the connection to the ADK board is fully functional in both directions. However, if the screen rotates, someone hits back, the screen locks, etc, when the app restarts the openAccessory call to the USB manager always returns null. So students have to unplug the USB before the connection can be made again.
I've figured out the problem is related to the Input Stream, because if I don't start the Thread to receive commands then there is no issue. However that's not really a useful fix. :)
My code is here:
https://github.com/ME435/AndroidLibraries_v01/blob/master/src/edu/rosehulman/me435/AccessoryActivity.java
I just subclass my AccessoryActivity in apps like this...
https://github.com/ME435/LED-Toggle/blob/master/src/edu/rosehulman/ledtoggle/LedToggleActivity.java
It's not robust, but it's very simple for students. Thoughts on my issue?
Wacom's drivers have always been atrociously bad, so I'm currently working on a hack.
The main problem I'm having is with calibration on a tablet PC. And before you say anything: no, just no. I've tried literally dozens of drivers, and of the few that work, none allows calibration of Wintab input. You can calibrate MS Ink, but that does nothing for apps like Photoshop that don't support the Ink API.
Having researched the issue a bit, the way I plan to hack it is by writing a wrapper for wintab32.dll which adjusts data packets as they're sent to applications, enabling calibration and perhaps tweaks to pressure sensitivity and whatever else I feel Wacom should have supported all along.
The calibration function is trivial, as is wrapping wintab32.dll and getting at the data that needs calibrating. As far as I can tell there are about half a dozen functions that request packet data, and I've inserted code in each of them to modify said data.
It works, too, at least if I test it on some wintab sample projects.
Photoshop is different, though. I can confirm that it loads the wrapped DLL, opens a wintab context and uses the API to request packet data, which is then modified en route. But then Photoshop ignores the modifications and somehow gets at the original, uncalibrated data and uses that. I can find nothing in the Wintab documentation to suggest how this is even possible.
I'm pretty stumped. Any thoughts?
Could it be that Photoshop only requests packets from Wintab in order to clear the packet queue, and then does something else to actually read the state of the stylus? And if so, what could that be? Some secret, obscure way of polling the data using WTInfo? A hook into the data stream between Wintab and the underlying driver/serial port?
I'm not very sure, but maybe the input from Ink API is also being written on the canvas. I mean, you are writing using two inputs now, which is WinTab and Ink. Got it?
If only you could ignore the Ink input, then that will show the right result.
P/S: This is only a hunch.
TL;DR available at the bottom
I've been trying to figure out a way to get two laptops (both running Ubuntu) to be able to pass basic messages back and forth without the need for them to be connected via a wireless network,either by an AP or ad-hoc. I want to reiterate here that ad-hoc networking is not what I'm looking for, I've seen many similar questions here with that as the answer.
I guess what I'm asking is: how do I achieve this? All I really need is for one computer to be able to send a packet, and then for another to pick it up via a packet sniffer of some kind.
Currently: I have both laptops in monitor mode (via a mon0 interface created from aircrack-ng's airmon-ng)so that they can sniff nearby traffic (with Wireshark, tcpdump,tcpcump.org's sample libpcap code, and opening a raw socket and just printing out all the packets. I tried each just because I thought one could be doing something differently/leaving something out). I also have a very basic program that consists of opening a raw socket to send crafted ethernet frames out to the air, but I can't get my two machines to see the other's packets. The sniffer running on each machine can only see the packets going out of that machine (in addition to nearby beacons/control traffic from wifi in the area).
Some things to note that might be important are:
-the packets I'm sending out appear in Wireshark (only on the sending machine) as malformed 802.11 packets (probably because I'm just filling them with junk data for now). I was under the impression that my other laptop would also see them as malformed packets, but it gets nothing
-the sockets I'm using are from a call to socket(PF_PACKET,SOCK_RAW,ETH_P_ALL). Raw sockets are something I just recently was aware of, so I could be misunderstanding how they work, but my impression is that I can craft a layer 2 packet by hand and ship out straight out to the wire/air.
If you're curious as to why I want to do something like this, it's part curiosity, part research for a project I'm working on. I want to streamline / automate the process of setting up an ad-hoc network, and what I'm trying to do here is for the laptops to do a small exchange to figure out the specifics of the adhoc network they are about to create and then make/join that network automatically, instead of either one person explicitly setting up the network OR having both people pre-decide the name, etc of the network and have both computers constantly trying to connect to that specific one.
I'm more interested if I'm going about this process in the right way rather than if my code works or not, if someone thinks me posting my (very basic, taken from another post on Stack Overflow) raw socket code will help, I can.
Edit: I am more than happy to post a complete set of code with instructions if I can get this working. I couldn't find much helpful info on this topic on the internet, and I'd love to put it up for future people trying to do the same thing.
TL;DR I want to send out a packet from one laptop and pick it up on another via a packent sniffer of some sort. No wifi network or ad-hoc network involved. Something akin to spoofing an AP's beacon frame (or similar) for the purpose of sending small amounts of data.
Edit 2:After some thought, perhaps what I'm looking for is some kind of raw 802.11 use? Having direct control of the wifi radio? Is such a thing possible?
I found out I was able to send packets out through my monitor mode interface as long as I had correct 802.11 with radiotap headers. I think the problem I was originally experiencing (not being able to sniff the packets) was because they were malformed and thus not actually getting sent out.
I was able to accomplish this by adapting the example code found here, courtesy of someone named Evan Jones, except I did not need to use an Atheros based card or Madwifi drivers, everything worked fine with the mon0 interface created with aircrack-ng.
I am certain that Apple Mac do this. Apple call it 'bonjour'. There may well be a proper IETF spec for it. This is an Article on Bonjour this is Wikipedia on an open component of bonjour which might help get you moving.
I've been assigned to upgrade an embedded application written in C. The application is configured via a web interface.
When the user modifies the web application a file is written to /var/www/settings.json and the file /var/www/UPDATE_SETTINGS is touched.
In the main application loop it checks to see if UPDATE_SETTINGS exists. If it does it parses the settings.json with json-c and then deletes UPDATE_SETTINGS.
This works well enough, however, we would prefer to move to an event-driven architecture (perhaps libev) in which settings.json is fed directly into the program by the webapp script to a plain-old UDP port and then issue a callback to perform the update.
What are some other elegant ways to solve this problem? Should we just stick with the current approach?
Just use inotify. It was created for cases like yours.
I am making some assumptions here.
1) you are connected to the internet all the time with you embedded device.
2) your device can set up interrupts on things like "USART RX buffer not empty"
note: depending on what kind of hardware you are using you could set up interrupts on things like pings and other stuff this could be another way of interrupting the embedded device.
if those two assumptions are correct you could do this, have another "script" on a server or computer somewhere that watches the /var/www/settings.json for changes you could use something like rsync to watch for changes. this "script" when it notices that the json file changes will communicate to the embedded device using tcp/ip you can either ping the device or just send the file over. If you can set an USART interrupt on the embedded device then the device will be able to detect the data coming in and therefore respond by either reading the data you are sending or going to the website to download the json file to be parsed.
this way you will have an event drive embedded device and it will not waste time checking to see if this json file has changed.
I hope this helps