Hi,
I need the complexity level to be similar in the encoding and decoding processes as I need to use it online i.e. simultaneous encode decode process....
If encoding and decoding processes do not take same time(same compexity) then there will be a mismatch at the decoder...
If i want to play an audio file after encoding and decoding online then there will be problems...
Does FLAC or WavPack has offer this feature..??

Here's a chart that shows the encoding and decoding speed of various lossless codecs with different settings, maybe it helps you:
http://web.inter.nl.net/users/hvdh/lossless/All.htm

WavPack, by default, works symmetrically. It can work asymmetrically.

FLAC works asymmetrically.

However, I don't really see that this is a requirement for you - I think an asymmetrical process would just restrict you to the slower process, and not make the system unworkable.

However, as WavPack is symmetrical by nature I would suggest WavPack anyway.

Edit: spelling

I don't see what problem it would cause... Care to elaborate, out of curiosity?

Unfortunately, that chart is outdated. It doesn't feature latest Wavpack versions, that are much faster than 4.0 in decoding speed.

For a more up-to-date chart, check out guruboolez'

If the process is asymmetric then I think I will face problems. If my requirement is to take audio data from a CD/DVD, which is being played by some player, encode and then transmit. On the receiver side I am decoding it and playing again...I need the process to be synchronous... In case of asymmetric process there will be lack of data for some time at decoder, as it has played the frame and waiting for the next frame but the encoder is taking time(more than decoder to decode) to encode and send it....
So is how I see the problem.
If you have a solution please suggest...

Hehe. "Symmetric", in lossless codecs, means that encoding and decoding take the same time to be performed. WavPack, Monkey's Audio...

Assymetric, on the other hand, are codecs that take longer to encode than decode. FLAC, ALAC...

this is not an encoding/decoding speed issue, it's a network protocol one.

if the encoding is faster than realtime, it can already send data fast enough and the receiver will implement some flow control (to tell the sender to pause temporarily). if it is slower, the receiver will have to buffer some data before starting playback. this is a common problem in streaming and there are several protocols to address it.

Josh