Wav Transmission Packet Loss?

Hey VB'ers. I am in somewhat of a predicament. I have an applet that transmits raw wav files to a VB server which then writes it to a wave file directly. The server works perfectly on small stream times, several minutes etc. However my targeted time is 2 hours. The applet also writes locally to the system that is broadcast. There is a HUGE difference! Like 1/2 gig difference.

I am suspecting either my vb app cannot keep up enough, or there is some packet loss... Now my question... What would be the best way for my program to recover from such loss of a packet, how to detect it, that way once my program writes the wave footer and closes the file it works perfectly.

Anybody had any somewhat similar experience? Any and all help appreciated :)

Well, first of all, you should encode(compress) the wave data, and then send it over winsock.
If you send more than your internet connection can take, then of course you have packet loss...

Also, are you using UDP connection ?
If you are using UDP, you should know that it does not guerantee packet delivery... only TCP does, but even TCP looses packets when it is overflowed (i.e. too much data to send)

If you want to send sound over the net, you should look at my project here:
http://vbforums.com/showthread.php?t=418770
And you will see that it records in wave, then it encodes in MP3, and only then it will send over Winsock.

I'm using TCP, and using pretty much the lowest resolution for a wave file... 16 bit, sample rate of 8000 in bits, mono channel, signed, big Endian false... also I searched back and your header/footer wave file theory didn't seem to work quite right on my application, something I wish to explorer later... not a big issue as of yet.

How do I detect an overload? Can I correct it somehow have my application fill the wave file with blanks or what not? In your opinion what would be best?

BTW I'm still exploring options here on my program... The only part that is VB is the server, (not the best choice but work with what you got), and the rest is created in java for web useage.

*bump*

(Sorry :()

Well, 8000 Hz, 16 Bits, is 2KBytes / second... even with phone line connection it should be OK... but even then I would compress if I were you, with the same size, you can get much better quality...

Anyways, I don't think it's overflowing (knowing that it sends 2K/second), so then you must have a mistake somewhere else... show the code where you send the data, and where you read the data...

part of the program is to be realtime collaboration, so maybe I'm sending the packets too quickly in binary in java? I'll pull the code for ya tommorrow, on another machine.

cvmichael, here you go... password to open zip file is on its way.

You know, you don't have to hide the code... there is no harm if you post the code for everyone, you will have more help other than me...

Anyways...

One mistake I see is here:

VB Code:

Private Sub Winsock1_Close(Index As Integer)
    WaveWriteHeaderEnd Index
End Sub

You are passing the Index of the socket, but it needs the file number...
It should be like this:

VB Code:

Private Sub Winsock1_Close(Index As Integer)
    WaveWriteHeaderEnd iFileNo
End Sub

And on top of that, you put the line "On Error Resume Next" in WaveWriteHeaderEnd, so you won't even get an error when you pass the wrong file number to it...

And why you use 2 sockets ?

I just noticed that you are using the winsock index number as file number...
You really should use the FreeFile function to return the free file number...

Also, I looked at your DataArrival event, and I don't see anything wrong...
Try getting the data into a byte array:

VB Code:

Private Sub Winsock1_DataArrival(Index As Integer, ByVal bytesTotal As Long)
    Dim sData() As Byte
    
    On Error GoTo Winsock1_DataArrival_Error
    
    Winsock1(Index).GetData sData, vbByte + vbArray
    Put #Index, , sData
 
Winsock1_DataArrival_Error:
    If Err.Number = 52 Then
        Put #Index + 1, , sData
    End If
End Sub

But you really have to get rid of the Index as file thing... especially when I see how you handle the error in this function...

yeah I know the code is really flawed its still just being tested and thanks.

The reason for the other winsock server is because other clients are going to be connecting to the server and then i'm gonna have the code spit back out the stream its inputting. It's multithreaded so it can be like icecast and have mounts if you have used that before.