Hey
I have the arduino mega and i would like to create a project in wich i will receive sound from a ptt and send it via ethernet.
I would like to start with the voice sampling.
Can you please help me with doing that?
Thanks
I don't think the Arduino has enough processing power for VOIP ( voice over Internet Protocol ).
Why not? Where is the problem?
I thought that i only need to sample the voice signal and send it using the ethernet library functions
Where is the problem?
Ethernet sends information in packages wrapped up with headers and footers and check sums surrounding the data. In addition you need a time stamp to say when this data should be played.
Packets do not necessarily arrive at the far end in the order they are sent. So to receive the sound you have to unpack the data packages and buffer them and only play them at the right time. Ethernet is not a real time transport system.
I can't tell much about arduino Ethernet board because i never used one and i never saw how the libraries
work but I can tell you something about protocols, if the Ethernet board is capable to use the protocols
and got them embedded inside the lib's give a look at the UDP Protocol this protocol is
used in VOIP and known softwares as msg, skype, whatsup, viber and others. This protocol is capable
to send only in a single direction and it's used mostly to transmit video and audio.
Read about the UDP protocol, sadly that i never used a Ethernet arduino board i could tell you more,
but as a Ethernet board it should be able to use the internet protocols, if there is no such lib. to use
the protocols you need then it's really sad.
EDIT: I gave a look on the internet and saw that Arduino Ethernet board is using UDP protocol and got a
lib as well, nice, really nice, it got me exited as well gonna buy a board in the future.
That's means you should be able to send voice/sound thru Ethernet.
D.60
That's means you should be able to send voice/sound thru Ethernet.
No it doesn't.
It is one thing to use UDP protocol and a whole world away to use UDP protocol to implement VOIP.
No it doesn't.
It is one thing to use UDP protocol and a whole world away to use UDP protocol to implement VOIP.
So let me see.
You got a arduino ethernet board a sd card, you record your audio thru a microphone, save it rapidly to a sd card and send it thru ethernet LAN or WAN thru the UDP protocol. What's the problem? Can't you transmit audio?
For faster processing the Personal Computer use Ram to save the audio and transform it to a digital signal, after that the UDP Protocol put the necessary size packets and send them one after the other thru WAN,
the packets are received, unpacked and transformed to analog signal again and coming as output from your
speakers.
D.60
So try it if you can't understand what I said.
By the way the OP talked about a microphone not a file in an SD card. And hearing the sound at the other end not storing it in a file.
For faster processing the Personal Computer use Ram to save the audio and transform it to a digital signal,
You clearly do not know what you are talking about. A personal computer first converts an audio signal into digital before storing it in RAM. Not what you said.
You clearly do not know what you are talking about. A personal computer first converts an audio signal into digital before storing it in RAM. Not what you said.
I really need to explain every step to make it clear how it's working, aren't you a PhD or something?
even a middle school kid would say no need to explain i know how it's working.
How the hek would you expect to send a clear analog signal thru WAN ? 
D.60
Udp was my choice also...
But my main question is how do i sample the voice signal?
Do i use one of the analog pins or maybe there is a unit dedicated for that?
Thanks
Your problem is that not only do you have to sample the analogue signal at a steady constant rate but you have to interleaved that with the buffering of the data and the sending of the package.
You ask advice and I give it. If you choose not to accept it then I will leave you in the incapable hands of our Mr. D60
@Domino60 - your command of English is too poor for you to explain anything correctly, nor understand when anyone corrects you.
@Domino60 - your command of English is too poor for you to explain anything correctly, nor understand when anyone corrects you.
Dear Mr.Grandpa
My English (grammar) maybe are not so good because that's not my
native language but wasting time in every single post telling me about
my english it's waste of time and annoying, I know more than 4
languages and maybe that's my weakness because I confuse the
understanding of other languages in my english writing and that's
what most of the people are confused about but what i write doesn't
mean that I write bullsht It makes perfect sense at the end if you
give a hard 2nd look of what I'm talking about.
I hope you understand, we are not all the same, we are different
and that's what makes our communication so hard, so I hope
next time our road crosses in this chat we will keep the conversation
calmly and on topic.
Sincerely,
D.60
Have a look at this benchmark thread
With a max rate of <10khz for ADC readings, sampling and forwarding only is challenging for a mega.
Should check (test? measure?) any delays and performance of ethernet/udp libraries
EDIT: Don't know if this helps - most ethernet cables have 4 pairs of wires, ethernet uses 3. Depending on your switching/wiring conditions you may try to use the spare pair for sending audio directly to the switch location where you presumably have more cabling/processing options.
Assuming the voice signal can be presented at appropriate analog levels, you "receive sound" by using the analog to digital converter to sample the data at fixed intervals. The Arduino API to the analog to digital converter is "analogread()". "analogread()" is fairly slow and is a blocking function, that is, the processor can't be doing something else while it waits for the conversion to complete. This doesn't give you much time to complete whatever processing is required for the UDP stream.
The atmega2560's A/D converter hardware supports a continuous sample mode which can interrupt the processor when each conversion is complete, so the processor is free to do something else (like support the UDP stream) during each conversion interval. This mode, however, is not directly available via the Arduino high level API, you'd have to do register mode fiddling which is not beginner friendly territory.
I haven't used an Ethernet shield with Arduino, but my impression is that simply sending raw samples over a UDP stream isn't particularly processor intensive for the Arduino as most of the magic happens on the shield side. Even a simple mu-law or a-law compression scheme to go from 12 bit samples to 8 bit transmitted data using interpolated lookup tables is doable on this class of processor, but more involved compression schemes are likely not.