setting timestamps for audio samples in directshow graph

I am developing a directshow audio decoder filter, to decode AC3 audio. the filter is used in a live graph, decoding TS multi开发者_开发问答cast. the demuxer (mainconcept) provides me with the audio data demuxed, but does not provide timestamps for the sample.

how can I get/compute the correct timestamp of the audio?

---

I found this forum post:

http://www.ureader.com/msg/14712447.aspx

In it, a member gives the following formula for calculating the timestamps for audio, given it's format (sample rate, number of channels, bits per sample):

With PCM audio, duration_in_secs = 8 * buffer_size / wBitsPerSample / nChannels / nSamplesPerSec or duration_in_secs = buffer_size / nAvgBytesPerSec (since, for PCM audio, nAvgBytesPerSec = wBitsPerSample * nChannels * nSamplesPerSec / 8).

The only thing you need to add is a tracking variable that tells you what sample number in the stream that you are at, so you can use it to offset the start time and end time by the duration (duration_in_secs) when doing linear streaming. For seek operations you would of course need to know or calculate the sample number into the stream.

Don't forget that the units for timestamps in DirectShow are typed as REFERENCE_TIME, a long integer or Int64. Each unit is equal to 100 nanoseconds. That is why you see in video filters the value 10,000,000 being divided by the relevant number of frames per second (FPS) to calculate timestamps for each frame because 10,000,000 equals 1 second in a REFERENCE_TIME variable.

---

Each AC-3 frame embeds data for 6 * 256 samples. Sampling rate can be 32 kHz, 44.1 kHz or 48 kHz (as defined by AC-3 specification Digital Audio Compression Standard (AC-3, E-AC-3)). The frames themselves do not carry timestamps, so you needs to assume continuous stream and increment time stamps respectively. As you mentioned the source is live, you might need to re-adjust time stamps on data starvation.

Each AC-3 frame is of fixed length (which you can identify from bitstream header), so you might also be checking if demultiplexer is giving you a single AC-3 frame or a few in a batch.