Reciever Client bad audio format

Please post bug reports, feature requests, or any question regarding the DELPHI AREA products here.

Reciever Client bad audio format

Postby Andyh » May 19th, 2009, 6:37 pm

Broadcaster and reciever demo application works perfectly whilst running simulaneously on the same (XP Pro) machine/s. When the programs are run on different machines accross the network the receiver (client) responds with : The specified format is not supported or cannot be translated. Use the capabilities function to determine the supported formats.

The actual format displayed on the client (for a brief moment is 4.192 kHz, 11832 Bit, 70 Ch, which is nonsense). The programs always work correctly together when run simultaneously on the same computer, is it some kind of timing issue i wonder?

Does anyone have any ideas on making this fine program work?
Andyh
Active Member
Active Member
 
Posts: 5
Joined: May 19th, 2009, 6:26 pm

Re: Reciever Client bad audio format

Postby Kambiz » May 19th, 2009, 7:21 pm

Maybe there are some packet loose in your network.
Kambiz
User avatar
Kambiz
Administrator
Administrator
 
Posts: 2408
Joined: March 7th, 2003, 7:10 pm

Re: Reciever Client bad audio format

Postby Kambiz » May 19th, 2009, 7:29 pm

By the way, broadcaster and reciever codes are only for demonstration of the package. It's better to use broadcast or multicast protocols to broadcast audio.
Kambiz
User avatar
Kambiz
Administrator
Administrator
 
Posts: 2408
Joined: March 7th, 2003, 7:10 pm

Re: Reciever Client bad audio format

Postby Andyh » May 19th, 2009, 7:35 pm

I'm not so sure. On the client, if i put a break point on the the procedure below:

procedure TMainForm.tcpClientRead(Sender: TObject; Socket: TCustomWinSocket);

at this point

Data := AudioBuffer.BeginUpdate(DataSize);

and step through 7 cycles monitoring 'data' i get the following values

$EE7450, $EE7BE8, $EE9C10, $EE7464, $EE9468 , $EE7464, $EE9468

then if i remove the breakpoint and continue running the client application it works OK.
Andyh
Active Member
Active Member
 
Posts: 5
Joined: May 19th, 2009, 6:26 pm

Re: Reciever Client bad audio format

Postby Kambiz » May 19th, 2009, 7:49 pm

In my home network the application works fine. But as I said, it's not written professionally and I do not recommend to use it as a base.
Kambiz
User avatar
Kambiz
Administrator
Administrator
 
Posts: 2408
Joined: March 7th, 2003, 7:10 pm

Re: Reciever Client bad audio format

Postby Andyh » May 20th, 2009, 7:30 am

OK, well thanks for the dem app and suite anyway. If i find a solution I'll post it up. The 18 Byte header buffer is not being received correctly, together with all the other data for some reason.

Thanks again.
Andyh
Active Member
Active Member
 
Posts: 5
Joined: May 19th, 2009, 6:26 pm

Re: Reciever Client bad audio format

Postby Andyh » May 20th, 2009, 11:47 am

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.
Andyh
Active Member
Active Member
 
Posts: 5
Joined: May 19th, 2009, 6:26 pm

Re: Reciever Client bad audio format

Postby Kambiz » May 20th, 2009, 1:34 pm

Try this

Code: Select all
procedure TMainForm.tcpServerAccept(Sender: TObject; Socket: TCustomWinSocket);
type
  TWaveFormatInfo = packed record
    WaveFormatSize: Integer;
    WaveFormat: TWaveFormatEx;
  end;
var
  WFI: TWaveFormatInfo;
begin
  SetPCMAudioFormatS(@WFI.WaveFormat, LiveAudioRecorder.PCMFormat);
  WFI.WaveFormatSize := SizeOf(WFI.WaveFormat);
  Socket.SendBuf(WFI, SizeOf(WFI));
end;
Kambiz
User avatar
Kambiz
Administrator
Administrator
 
Posts: 2408
Joined: March 7th, 2003, 7:10 pm

Re: Reciever Client bad audio format

Postby Andyh » May 26th, 2009, 2:27 pm

aha that fixed it.

Cool program using it to provide a proof of concept for a new analogue telephone audio monitoring project.

Thanks again.
Andyh
Active Member
Active Member
 
Posts: 5
Joined: May 19th, 2009, 6:26 pm


Return to DELPHI AREA Products

Who is online

Users browsing this forum: No registered users and 1 guest

cron