I don't want to prolong agony on this but is it possible that this may be the problem? You can duplicate the issue If you simulate network latency by putting sleep(10) (or more in the sender application where described below). You can then run both the sender and the receiver on the same PC and get a problem where the waveformat structure has not been initialised correctly.
Maybe when running on the same PC or on a fast network the 2 seperate sends (the structure size then the structure itself) are being sent so quickly they are recieved as a single receive of 22 bytes in length (integer + TWaveFormatEx) the receiver application is able to reallocate the Waveformat structure and populate it correctly with the 22 bytes of data sent and then sets the liveAudioPlayer.Active := True, stopping it from happening again.
If the reciever application receives the data slower it sees the 2 sends as being seperate (tcpClientRead gets called twice) so it gets the first 4 bytes of data -the structure length- then tries to initialise the TWaveformatEx structure with the 4 bytes (it needs 18) then you get the problem?
So, if both on the sender and reciever you do away with the sending and recieving the length buffer (assuming 18 as the value on the reciever) then it will work on a slow network or when the sleep command is introduced. Or better still send the length and data as one send transmission?
- Code: Select all
procedure TMainForm.tcpServerAccept(Sender: TObject; Socket: TCustomWinSocket);
var
WaveFormat: TWaveFormatEx;
WaveFormatSize: Integer;
begin
SetPCMAudioFormatS(@WaveFormat, LiveAudioRecorder.PCMFormat);
WaveFormatSize := SizeOf(WaveFormat);
Socket.SendBuf(WaveFormatSize, SizeOf(WaveFormatSize));
sleep(10); //this replicates the problem i am having.
Socket.SendBuf(WaveFormat, WaveFormatSize);
end;
What do you think?
Andy.