This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How to get PCM data from microphone in C++ (os Windows)?
How can i capture sound from the microphone, and hear it in another computer live?
Thanks.
The simplist way is to use the waveIn functions provided by the Win32 API.
You can read Recording and Playing Sound with the Waveform Audio Interface for an overview, or just dive into the API documentation.
To record, you can use the waveIn functions in win32API.
BUT before you send it, remember that the data got in the byte-buffer through waveIn function is PCM format, and it will easily clog your NETWORK. You must first compress the PCM data into aLaw or uLaw format before tunneling it through WinSOCK Apis. Otherwise, it will surely NOT be a "live" feed, also taking up a lot of bandwidth.
Another easy solution for audio i/o is portaudio. Aside from being portable, it's very easy to use.
To get audio data over the network, as another answer pointed out, you should be aware that your data is huge. However, a good place to start is to try sending raw data. Once you can do that, then you can worry about compressing it -- you need to solve a complex problem one step at a time. Eventually, you'll probably want to use UDP for the raw audio packets.
A good library for sending audio, video, chat and other data is google's libjingle which implements the google talk protocol. It has solved many of the issues with UDP vs TCP, firewalls etc. You may find it a bit hard to work with anyway as it's a lot of code and you'll need to work with XMPP which you may not be familiar with. Also, it's C++, not C. It also requires some server mediation, although you can use google's servers. If that doesn't work for you you can do something home grown but you may find you need to do a fair bit of work to get it all right.
I am sure there are some libraries to help you. Try googling for things like "internet telephony library c" and "voip c library" (even though this is not, in the strictest sense, voip)
Related
I have an obsolete hardware level/pressure transmitter that communicate with mcu using custom protocol (it appear to be similar to modbus RTU), that hardware comes along with an old commissioning software that works perfectly fine under latest windows, that software contain all communication protocol components that I try to extract and use in something like Arduino to pull data out of transmitter, anyone can help out?
Update - Didn't mentioned above that form of communication here is half-duplex serial communication where master hardware/software query slave transmitter.
Now mentioned to program Arduino mcu to pool data out of transmitter.
What best way of getting readable data out of it?
Again many thanks for all your comments and help!
What you need is called a sniffer. Use that as a keyword and you should be able to find plenty of info here at SO and around the web.
To set the record straight it is actually possible to use Wireshark to sniff on Modbus RTU over serial, see my answer here. If your protocol is similar to Modbus I would start with SerialPCAP.
If you prefer more Windows-friendly solutions you can check these out: 1, 2.
Since Modbus is pretty simple I would say reverse engineering a similar protocol should be, maybe not a piece of cake but just manageable, even if you are not very experienced.
These days when almost everyone is a maker or at least a wannabe, you might want to first take a good look around, maybe somebody else already reverse-engineered that protocol and published it somewhere.
The best tool to analyze a protocol is Wireshark. Run it on the communication link between the Windows machine and the radar. First possibility: the protocol is actually something that Wireshark knows (some trials and errors with the "Decode as" menu may be necessary.) Second possibility, less funny: the protocol is indeed completely proprietary and unknown to Wireshark. At least, Wireshark will make it easier to examine the binary data.
I have a zigbee2mqtt / home assistant setup working fine, and I'd like to try to make my own simple devices to connect to that network.
I got an xbee 3 board, and using micropython to start with I was able to connect to my network.
However the "interview" fails. The xbee receives a message with a cluster 0, profile 260 (home automation) and endpoint 230 (command). Not sure what the payload contains, that's not a string :
{'profile': 260, 'dest_ep': 230, 'broadcast': False, 'sender_nwk': 0, 'source_ep': 1, 'payload': b'\x10\x02\x00\x05\x00\x04\x00\x07\x00', 'sender_eui64': b"\x00\x12K\x00\x18\xe2I'", 'cluster': 0}
My question is what should I answer for the interview to succeed ?
I'm making only a basic sensor, I'd like to just report 1 weight reading periodically. I'm assuming I need to send back something saying I have one endpoint, on some cluster (not sure which, I guess something in the 400s) but I don't know what the format should be.
I couldn't find much info on this (baring how to use things like the Zigbee Cluster Library, which aren't python), any pointers or examples of end devices I could take a look at to understand how this interview process works ?
Unfortunately digi's examples all seem to involve xbee devices talking to each other, I couldn't find any examples of how to make a regular end device.
Thanks !
EDIT: Just found this great page which explains how this all works. Still need to figure out the exact bits I'll need and try it out, but now I know where to start !
This sounds a lot like the ZCL, and I'm not aware of an Open Source Python implementation of that protocol. Digi has an Open Source ANSI C Library that includes a ZCL implementation. If you can read C code, you might be able to decode that payload to see what it's asking. You might also need to handle some of the ZDO/ZDP (Zigbee Data Object/Device Profile) protocol on endpoint 0, by setting ATAO=3 (IIRC). There's also ZDO/ZDP code in that C library. (Full disclosure: I wrote most of the code in that library, including the Zigbee layer. But I haven't worked with Zigbee in a long time, so I'm rusty on protocol details.)
My recommendation would be to just hardcode hand-generated responses as much as possible. Figure out the expected format for requests, and determine what works as a response. If you can sniff the 802.15.4 traffic, or have your zigbee2mqtt gateway log activity with an existing device, you might be able to use its responses as a starting point for your implementation.
I want to get in the middle of packet forwarding (Not routing). For example, the system is a layer 2 bridge between hosts and their gateway. I want to check the layer 7 for string or whatever "foo" and forward/drop/delay the packet based on the result. What I am having trouble with is intercepting the packet.
What I have read so far:
I know I can get the copy of packet from BPF device (Usenix paper by Steven McCanne and Van Jacobson http://www.tcpdump.org/papers/bpf-usenix93.pdf ). that's good for sniffing but not for me.
I can access the PF device and set the filtering rules which is good for forwarding or dropping decisions, but not for inspection. man pf (4)
I can get packets into the ALTQ queues, BUT I do not know how to access the individual packets located in the queue. man altq(9)
I have also looking into the source code for PF(/usr/src/sys/contrib/pf/net ), PFCTL (/usr/src/contrib/pf/pfctl) and ALTQ(/usr/src/sys/contrib/altq/altq).
On FreeBSD 9.1 machine
I am not C expert, but I am good with it.
Maybe I am getting tired today with all the reading and missed something trivial. Please forgive me if so. Plus, this will be a very good find fro those looking into the subject.
P.S. There is a way of controlling the flow of "foo", by detecting "foo" in packet and denying the answer to that from coming back by setting up the filter for answer to that request. This is NOT what I am trying to achieve. I do not want the packet to leave the system if it should not.
EDIT 2 P.S. There is a great way of doing this on Linux. I can achieve everything I mentioned here on Linux with libnetfilter_queue. I will not bother posting solution here because there are many many many tutorials on how to do it on Linux.
In conclusion, I am still looking for answer on how to do this on BSD. As far as I can understand, I need to write a wrapper/library based on pf (because there is no such thing on the net - otherwise I should have found it already), that does the same thing as libnetfilter with it's libnetfilter_queue library. Or I could somehow dig into libnetfilter and port it to FreeBSD, but since it is based on iptables, only thing I can get from digging into libnetfilter library is logic and algorithms not the actual code itself, which by itself could prove to be of no use to me.
FreeBSD 9.1 has an userspace framework for packet access called netmap. It was recently introduced and has an amazing performance scale. It does very simple but powerful thing - just mmaps the NIC buffers to userspace portion of memory and detaches the packet processing from host stack, this was exactly what I needed the rest is on me.
If anyone needs any goods reference for this, please refer to man netmap (4)
Have a look at OpenDPI or nDPI.
Check out the "Divert Sockets" in BSD implementation as well. Unlike Netmap, it is not zero-copy (IMHO) however it can work with ipfw in order to implement the necessary filters in order to filter packages you want to process.
I'm working on a streaming audio player for Linux/OS X with a bizarre use case that has convinced me nothing that already exists will work. For the first portion, I just want to receive MP3 data and play it. I'm currently using libmad for decoding and libao for playback. My problem is with libao, and I'm not convinced it's my best option.
In particular, the ao_play function is blocking. It doesn't return until the entire buffer passed to it has been played. This doesn't give enough time to decode blocks between calls to ao_play, so the decoding has to be done either entirely ahead of time, or concurrently. Since this is intended to be streaming, I'm rejecting ahead-of-time decoding offhand. (It's conceivable I could send more than an hour's worth of audio data - I don't want to use that much memory.) This leaves concurrency. But while pthreads is standard across Linux and OS X, many of the surrounding libraries are not. I'm not really convinced I want to go to concurrency - so I'm reconsidering my choice of libao.
For my application, the best model I can think of for audio playback would be getting a file descriptor I could select on to get notified when it's ready for writes, then issue non-blocking writes to. (This is due to the rest of the details of the use case, which imply I really want a select loop anyway.)
Is there a library that works on both Linux and OS X that works this way?
Although it's much hated, PulseAudio basically works exactly like you describe (using the Asynchronous API, not the simple one).
Unless what you want to do involves low-latencies or advanced sound work, in which case you might want to look at the JACK Audio Connection Kit.
PortAudio is your one. It has a simple callback driven API. It is cross-platform and low-latency. It is the best solution if you don't need any fancy features (3D, audio-graphs,...).
This question might sound fool, because I know there are bunch of frameworks that does it for you. What I want is actually get in touch with low level C API deeply and able to write a program that sits on computer and intercepts packets between local machine and outer spaces. I tried to figure it out by looking at open source code (i.e. tcpdump) but it's quite difficult for me to find out which file actually performs network sniffing. Any suggestions would be appreciated !
You have to use raw socket. Here's an example.
At least for what concern Linux and Unix like operating systems. I don't know about Windows.
If you're using a UNIX based system[*] then the simplest mechanism is libpcap, which is part of the tcpdump project.
Your process will need root privileges to be able to access the network interface (as would also be the case with raw sockets).
Usually you'll end up having to decode ethernet frames, IP headers, etc yourself, although for most protocols this isn't that hard.
[*] It is actually available for Win32 as well, but I've not used it under Windows myself.