🚀 go-pugleaf

EDIT: I need to implement transmission of voice packets using ip packets, 
not VoIP because that involves alot of different things... I dont really 
care about encyption either. Just want to make something where I can talk 
back and forth, possibly p2p...


"Carl Danley" <cdanley@codebyter.com> wrote in message 
news:4868387c@newsgroups.borland.com...
> Alright... So, I've been reading a book for VoIP and have been wondering 
> whether or not I should even bother trying to implement a feature like 
> this into a program of mine... I was wondering if anyone on here would be 
> willing to work with me to help with creating some sample code so I can 
> understand the process in this language... I am decently experienced with 
> Codegear RAD Studio (C++) and write applications on a daily basis... My 
> understandings are that this isnt an easy task, but im tired of hearing 
> that and I want to learn this so that I can implement this type of feature 
> into a multitude of different applications. If you have any ideas as to 
> where I could get started or have some spare time to write some sample 
> coding, I would absolutely appreciate it! I have posted on several 
> different forums over the past year and no one has helped at all.. Thank 
> you again for your time!
>
> Also, if you have any questions, please ask! 

Carl Danley wrote:
> EDIT: I need to implement transmission of voice packets using ip 
> packets, not VoIP because that involves alot of different things... I 
> dont really care about encyption either. Just want to make something 
> where I can talk back and forth, possibly p2p...
> 
> 
> "Carl Danley" <cdanley@codebyter.com> wrote in message 
> news:4868387c@newsgroups.borland.com...
>> Alright... So, I've been reading a book for VoIP and have been 
>> wondering whether or not I should even bother trying to implement a 


Hi,

A couple of years ago, I have worked on a project on a project involving 
the transmission of voice over a network (not related to VoIP as is). 
After a lot of experimentation, I started building a system with a Linux 
server backend (pretty much functionnal) and a C++Builder Windows 
client. Eventually (after several months of spare time) I had to suspend 
the project because I was stuck on an almost complete system but without 
the knowledge to make it really usable. At the best time, I was able to 
send voice over the system, but the receiver would only get all cut 
piece of voice in a non continous basis. At that moment, I started 
looking for a partner, but coudn't find anyone interested. The system 
was called Aleck and did have a website. I still have all of the source 
code archived in the hope of someday resurect the project.

Let me know if you would like to discuss with me. We could exchange msn 
address if you like.

Sorry for my written English. Not only it is not my native language, but 
I'm very tired right now. I usually have better written English :p

Tom :)

Carl Danley wrote:
> Alright... So, I've been reading a book for VoIP and have been wondering 
> whether or not I should even bother trying to implement a feature like 
> this into a program of mine... I was wondering if anyone on here would 
> be willing to work with me to help with creating some sample code so I 
> can understand the process in this language... I am decently experienced 
> with Codegear RAD Studio (C++) and write applications on a daily 
> basis... My understandings are that this isnt an easy task, but im tired 
> of hearing that and I want to learn this so that I can implement this 
> type of feature into a multitude of different applications. If you have 
> any ideas as to where I could get started or have some spare time to 
> write some sample coding, I would absolutely appreciate it! I have 
> posted on several different forums over the past year and no one has 
> helped at all.. Thank you again for your time!
> 
> Also, if you have any questions, please ask!

(read the other post first)

Oh, and for the VoIP... Well you will never hear "forget it" from me, 
but let's say I had a peak at it a some moment and found that the whole 
protocol was very complicated, and looked messy to me. After some 
research, I decided never to make any experimentation regarding that, 
although I was very interested.

As for compression/encryption, I'm not even remotely close to something 
that you would call an expert, but I have bases for having experimenting 
a lot around that when I was wrong. Let's just say that part of my 
enthusiasm went away when I received a letter from a lawyer requesting 
that I stop distributing my implementation of the LZ78 algorithm, which 
was, to the best of my judgment, a poor non optimized only good for 
educational purpose implementation.

Tom :)

Actually, this sounds very interesting... My only thing is this: As I dont 
have the greatest experience with the whole process for sending voice 
packets over the internet, i would have to catch up on what you already 
know. I would be happy to work with someone on implementing this feature 
into a program. I'm not sure what I could help with but I'd love to help. In 
reference to receiving the voice packets all cut and choppy, out of order, I 
believe we would have to implement something to put them back into order... 
Sounds obvious, but this would imply some way to send a packet with the 
ordering so that when all of the voice packets have been received, the 
receiver can put them back into place... Anyways, I would love to work with 
you on this project, if I am capable, so that we may both further our 
understanding of the transmission of voice packets. I dont have MSN 
Messenger, but I can go get one if needed.

Carl :)


"Tom420" <tom420@sherbrooke.qc.ca> wrote in message 
news:4868458f$1@newsgroups.borland.com...
> Carl Danley wrote:
>> EDIT: I need to implement transmission of voice packets using ip packets, 
>> not VoIP because that involves alot of different things... I dont really 
>> care about encyption either. Just want to make something where I can talk 
>> back and forth, possibly p2p...
>>
>>
>> "Carl Danley" <cdanley@codebyter.com> wrote in message 
>> news:4868387c@newsgroups.borland.com...
>>> Alright... So, I've been reading a book for VoIP and have been wondering 
>>> whether or not I should even bother trying to implement a
>
>
> Hi,
>
> A couple of years ago, I have worked on a project on a project involving 
> the transmission of voice over a network (not related to VoIP as is). 
> After a lot of experimentation, I started building a system with a Linux 
> server backend (pretty much functionnal) and a C++Builder Windows client. 
> Eventually (after several months of spare time) I had to suspend the 
> project because I was stuck on an almost complete system but without the 
> knowledge to make it really usable. At the best time, I was able to send 
> voice over the system, but the receiver would only get all cut piece of 
> voice in a non continous basis. At that moment, I started looking for a 
> partner, but coudn't find anyone interested. The system was called Aleck 
> and did have a website. I still have all of the source code archived in 
> the hope of someday resurect the project.
>
> Let me know if you would like to discuss with me. We could exchange msn 
> address if you like.
>
> Sorry for my written English. Not only it is not my native language, but 
> I'm very tired right now. I usually have better written English :p
>
> Tom :) 

Carl Danley wrote:
> Actually, this sounds very interesting... My only thing is this: As I dont 
> have the greatest experience with the whole process for sending voice 
> packets over the internet, i would have to catch up on what you already 
> know. I would be happy to work with someone on implementing this feature 
> into a program. I'm not sure what I could help with but I'd love to help. 
> In reference to receiving the voice packets all cut and choppy, out of 
> order, I believe we would have to implement something to put them back 
> into order... Sounds obvious, but this would imply some way to send a 
> packet with the ordering so that when all of the voice packets have been 
> received, the receiver can put them back into place... Anyways, I would 
> love to work with you on this project, if I am capable, so that we may 
> both further our understanding of the transmission of voice packets. I 
> dont have MSN Messenger, but I can go get one if needed.

If you use the TCP/IP packet protocol, the packets are guaranteed to arrive 
in order.

HTH

Jon 

So, in theory I could open up a file stream, record to it, and send it over 
the TCP/IP socket? The receiving end would just grab the file and store it 
somewhere to play?

"Jonathan Benedicto" <invalid@nobody.com> wrote in message 
news:4868f8e6$1@newsgroups.borland.com...
> If you use the TCP/IP packet protocol, the packets are guaranteed to 
> arrive in order. 

Carl Danley wrote:
> So, in theory I could open up a file stream, record to it, and send it 
> over the TCP/IP socket? The receiving end would just grab the file and 
> store it somewhere to play?

Correct, though probably would give performance issues. Voip requires very 
low latency, so ideally you'd want to be sending lots of small packets.

Jon 

Is there a way to declare how big the packets are before they are sent? 
Also, I can code the majority of this, but the only thing i dont know how to 
do is send the file over the socket and open a stream to be recorded to... 
Any Ideas? Here is some coding that I would use for everything else:

//<-------BEGIN
TClientSocket * TCP = new TClientSocket();
//-----------------------------------------------------
TCP->Host = "something.com";
TCP->Port = 3980;
try
{
    TCP->Active = true;
}
catch(...)
{
    ShowMessage("Could not connect to server!");
};
//now i would need to insert the process to open a stream and start 
recording
//during the recording process, I would need to send a packet of XX size to 
the server component

//<-------END

I know that might be alot of potential coding, but I sure could use the 
help. Would it be possible to use the TMediaPlayer component to record to a 
stream and then send? or would I use an MCI Media Player?

"Jonathan Benedicto" <invalid@nobody.com> wrote in message 
news:48690105$1@newsgroups.borland.com...
> Correct, though probably would give performance issues. Voip requires very 
> low latency, so ideally you'd want to be sending lots of small packets. 

Carl Danley wrote:
> Is there a way to declare how big the packets are before they are sent?

Not really, because to limit the size of each packet you send, just send a 
few (<1000) bytes at a time.

> Also, I can code the majority of this, but the only thing i dont know how 
> to do is send the file over the socket and open a stream to be recorded 
> to... Any Ideas? Here is some coding that I would use for everything else:

You won't be sending a file, you'll most likely want to send a compressed 
audio stream as fast as it comes from the sound card.

> I know that might be alot of potential coding, but I sure could use the 
> help. Would it be possible to use the TMediaPlayer component to record to 
> a stream and then send? or would I use an MCI Media Player?

You'll probably want to use the waveIn API functions, or possibly DirectShow 
or a 3rd party component to get the audio stream.

Jon 

Would you happen to know where I could find some samples for these 
functions? like a how-to or something, just need something to look at and 
understand

"Jonathan Benedicto" <invalid@nobody.com> wrote in message 
news:486908a0$1@newsgroups.borland.com...
> You'll probably want to use the waveIn API functions, or possibly 
> DirectShow or a 3rd party component to get the audio stream. 

Carl Danley wrote:

>Would you happen to know where I could find some samples for these 
>functions? like a how-to or something, just need something to look at and 
>understand

No examples, but the help starts here.
(Mobile and CE docs, but should be ok for regular?)
http://msdn.microsoft.com/en-us/library/aa909799.aspx

Looks like
	waveInOpen()
	waveInPrepareHeader()
	waveInAddBuffer();
	waveInStart();

You can pass a callback function to waveInOpen that
is to process the buffers when they fill. It would
also make new buffers (recycled) available to be filled.

waveInPrepareHeader() sets the buffer size.
I would assume you could (and would want to)
add multiple buffers so you could TCP from one
while waveIn is filling the next.

I would also add that you would likely wish
to use TCP_NODELAY
	int	t = TRUE;
	setsockopt( mysocket, IPPROTO_TCP, TCP_NODELAY,
		(char*)&t, sizeof(t) );

Architecture folks architecture.
Have some ideas no code....

Communications of this type has two aspects (a) control and (b) data 
just like FTP.

Have the control work with TCP. and the data work on UDP.
What I mean with control is a TCP registration with a server, just like 
a chat session. You get your 'ip-phone' to be part of a voice extension 
based network like a pabx. The server knows you exists when you log onto 
the server.

If you have multiple users, then you can call someone. Just type in the
extension number. The server will know who is who (ext->ip translation)
and initiate a call.

The thing is what platform shall we agree on Indy9 or Indy10.
Delphi or C++...




Carl Danley wrote:
> Alright... So, I've been reading a book for VoIP and have been wondering 
> whether or not I should even bother trying to implement a feature like 
> this into a program of mine... I was wondering if anyone on here would 
> be willing to work with me to help with creating some sample code so I 
> can understand the process in this language... I am decently experienced 
> with Codegear RAD Studio (C++) and write applications on a daily 
> basis... My understandings are that this isnt an easy task, but im tired 
> of hearing that and I want to learn this so that I can implement this 
> type of feature into a multitude of different applications. If you have 
> any ideas as to where I could get started or have some spare time to 
> write some sample coding, I would absolutely appreciate it! I have 
> posted on several different forums over the past year and no one has 
> helped at all.. Thank you again for your time!
> 
> Also, if you have any questions, please ask!

(After reading other posts)

Just a few thoughts OTTH to maybe help out:

For help with the waveXX() functions check out the Multimedia help files 
in the for the SDK that come with Builder.

I have been looking at trying to do some audio stuff myself and seem to 
remember that recording involves a couple of input buffers (one filling, 
one saving). In playing back an audio file that can't fit into memory 
you would use enough buffers to hold about 2 seconds of audio. Fill one 
up start playing it, fill the rest, wait for 1 to finish playing, start 
2, fill 1 with more stuff, rise & repeat...:)

As I was reading the other posts, I was thinking that if one were to 
place the ->SendBuf() transfer in the between the record/fill and the 
fill/play operations of the standard record/play process and increased 
the amount of buffer to 3~4 secs. You would wind up sending continuously 
from the mic side to the play side, but it might work.

There used to be a site that had some good information 
(www.borg.com/~jglatt/tech/lowaud.htm) but I just checked and the site 
is gone now :(  Doing a search came up with some code:
(VB) 
http://www.planetsourcecode.com/vb/scripts/ShowCode.asp?txtCodeId=65662&lngWId=1

Another post said, "For samples on how to record audio with waveIn, 
there are plenty on codeguru.com."

And one more thought the MTU on my firewall is 1500 (bytes), so the size 
of your data buffers should take that into account.

DC


Carl Danley wrote:
> Alright... So, I've been reading a book for VoIP and have been wondering 
> whether or not I should even bother trying to implement a feature like 
> this into a program of mine... I was wondering if anyone on here would 
> be willing to work with me to help with creating some sample code so I 
> can understand the process in this language... I am decently experienced 
> with Codegear RAD Studio (C++) and write applications on a daily 
> basis... My understandings are that this isnt an easy task, but im tired 
> of hearing that and I want to learn this so that I can implement this 
> type of feature into a multitude of different applications. If you have 
> any ideas as to where I could get started or have some spare time to 
> write some sample coding, I would absolutely appreciate it! I have 
> posted on several different forums over the past year and no one has 
> helped at all.. Thank you again for your time!
> 
> Also, if you have any questions, please ask!

Carl Danley wrote:
> Actually, this sounds very interesting... My only thing is this: As I 
> dont have the greatest experience with the whole process for sending 
> voice packets over the internet, i would have to catch up on what you 
> already know. I would be happy to work with someone on implementing this 
> feature into a program. I'm not sure what I could help with but I'd love 
> to help. In reference to receiving the voice packets all cut and choppy, 
> out of order, I believe we would have to implement something to put them 
> back into order... Sounds obvious, but this would imply some way to send 
> a packet with the ordering so that when all of the voice packets have 
> been received, the receiver can put them back into place... Anyways, I 
> would love to work with you on this project, if I am capable, so that we 
> may both further our understanding of the transmission of voice packets. 
> I dont have MSN Messenger, but I can go get one if needed.
> 
> Carl :)

Hey,
I'm really sorry, I was unexpectedly thrown out the Internet for the 
past two weeks. To make a long story short, I moved out on July 1st and 
my ISP forgot about my request. I got the Internet back only this morning.

I just read the entire thread. I'm going to comment randomly to all of 
the discussion (sorry if I didn't keep track of who said what).

What I was doing in my system (Aleck) and all of the other testing 
programs before, was this:

Used WaveIn/WaveOut functions (from the Win API). Those are really easy 
to use. Basically, you have at least two buffers (more is better, but I 
found out through my tests that 2 were fine on my system, which was then 
a P3-500). Through the WaveIn functions, you give those buffers to the 
sound card and ask it to start recording. The sound card notifies as 
soon as one of the buffer is filled. You process the buffer and put it 
back in the sound card's queue. The reason why you need more than one 
buffer is that the sound card does not have any other internal level of 
buffer of any kind, so if you have just one buffer, you would miss some 
of the recording as you process the single buffer before you give it 
back. So basically, the sound card start filling the second buffer while 
you are processing the one which is complete. For playing back, you just 
give the sound card some filled buffers (using WaveOut functions) and 
ask it to play them. Again, you need to have more than one, so it can 
play the next buffer as you are preparing a new one.

Of course, the interesting part is in between the recording and playing 
back steps (cause well, you are not going to listen to yourself).

Once you have one filled buffer (a waveform with some of your pretty 
voice in it) you have to compress it (uncompressed high quality wave is 
too heavy for regular Internet use, although it might be acceptable on a 
local network). There is a number of audio compression algorythms 
available out there, the most well known being MP3. However, MP3 is 
designed for music. It is not optimized for voice-only and thus gives a 
big file for a nominal quality level. In my system I used Speex, it's a 
high quality, free (open source), audio codec specialised for voice. It 
is in fact the default codec used by TeamSpeak (a 
voice-over-the-internet software especially designed for used while 
playing games over the net). It is relatively easy to use, has a low 
latency (when used correctly), very resistent to packet loss (you can 
loss 70% of the packets and still play back a voice message that is 
surprisingly clear).

Once you have a buffer containing some compressed audio data, comes the 
time when you send the buffer to your peer through the Internet.

At the other end, the receiving program will uncompressed the audio data 
back to a waveform and play it back using WaveOut.

The main goal is to reduce the latency (that is, the time between the 
moment you speak into your microphone and the moment your voiced is 
played back on the other computer) to a minimum. As such, you want to 
create as small sound buffers as possible (the length of the buffer is 
the first latency cause... that is, a one-second buffer makes a 
one-second delay). IIRC, Speex used 30 ms buffers. Then, you want to 
process the buffer (apply any sound effect [normalize volume, add echo, 
...], compress, and queue to be sent to the peer) as fast as possible. 
Here some optimization (and a good choice of codec and algorithm and a 
good machine) is important. This is the second cause of latency. The 
third cause of latency is the Internet (here you can't do much). 
Decompression and possibly more audio processing is the last latency cause.

Last, for the playback to be smooth, the receiver needs to build some 
form of queue and impose a small delay before playing back the first 
buffer, because the Internet does not guarantee that the buffers will be 
received at a regular interval, Internet delay would cause playback 
cuts. And this is precisely where I had problems. When I tested with the 
sender and receiver on the same machine, the playback was perfect. But 
the there was that beast called the Internet in between, there were no 
way to recreate a clear voice playback, no matter the length of the 
delay imposed. And let me tell you, you hear isn't fine enough to follow 
a conversation, 30 ms at a time.

BTW, I always used TCP during all of my tests (no UDP), so packet order 
was never a problem. But of course, if you use UDP (or some other 
protocol where the packets are not guaranteed to be received in the 
order sent) you need some synchronization mechanism, the most obvious 
being to simply number the packets and replace them in order as they are 
received.

So well, this is pretty much were I've been. Aleck has been stopped for 
over 3 years now, after several months of development and a lot of efforts.

If you wish to contact me, try MSN Messenger at tom@tom420.com (not 
valid as an e-mail address -- specify who you are when adding to avoid 
rejection). Just don't make assumptions. I have projects of my own right 
now, so even thou you convince me to help you, there is little chance 
that I will be able to join a project in the short-term. That said, I'd 
really like to talk with you nevertheless, we never know where that 
would take us :)