Appro IPNC & G711 Audio Encoding : Problem with Streaming in RTSP

An information I found when printing debug messages in stream.c : I printed the timestamps of the audio frames when put on the shared memory and they are all separated by 256 ms. When each frame is considered to be 125ms long, and since we are in mono, it is strange to see this gap. Do not know yet if this gap results in the discontinuous audio signal heard in VLC. What I can see anyway is that the network RTP data payload are separated by the same amount of around 250ms. So the problem may come principally from the av_server and not wis-streamer ?

Any clue ? Is that a known bug on the version 1.0 ?

Hi,

Version 1.0 is more than a year and half old release. can you please migrate to latest release avaialble at Appro ftp site and check if this issues exists?

Regards,

Raghu

Hello Raghu,

We are in the course of migration (ordering version 2.5 from Appro is in the pipe). I wanted to be sure that the problem was identified on the 1.0 version and had been fixed on subsequent versions, and especially the 2.5 we are ordering.

Thanks for your info about this topic.

HI, version 2.6 should be uploaded this week. Please use this as this will be the latest.

Regards,

Raghu

Hi Raghu,

my TI sales representative told me that for DM365 there won't be any more version above the 2.5. Are you sure the version 2.6 is for this device or is it for DM368 ?

Thanks

Version 2.6 is for DM365 as well as for DM368, it is a common release.

This should be uploaded at Appro ftp site by this week

Regards,

Raghu

Version 2.6 for DM368, is fixed ?
I test H264 1080P & G.711 Audio in version 2.6, but video is not smooth and audio is not continues.

Hi,

Can you please give more details on the issue you are facing, please share the logs and recoded avi files with audio/video

one more check, have you updated the UBL, uboot from the v2.6?

Regards,

Raghu

I am updated the UBL and U-Boot to v2.6.

But that has bad block table found message in boot time.

I test configures as follow,

H264, D1 Audio OK

      720P/1080P Audio not continues

MPEG4, D1/720P Audio OK

       1080P Audio not continues

----------------------------------------

DM36x initialization passed!

TI UBL Base Version: 1.50

Boot Loader BootMode = NAND

Starting NAND Copy...

Valid magicnum, 0xA1ACED66, found in block 0x00000008.

Boot Mode Task Completed

IPNC UBL Version: 1.1.0

Platform: DM368

Jumping to entry point at 0x81080000

U-Boot 1.3.4 (Dec  9 2010 - 17:44:14) DM368-IPNC-1.0.1

I2C:   ready

DRAM:  128 MB

NAND:  NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND 128MiB 3,               3V 8-bit)

Bad block table found at page 65472, version 0x01

Bad block table found at page 65408, version 0x01

128 MiB

In:    serial

Out:   serial

Err:   serial

ARM Clock :- 432MHz

DDR Clock :- 340MHz

Ethernet PHY: GENERIC @ 0x01

Hit any key to stop autoboot:  0

DM368 IPNC :>

-------------------------------------------

Hello,

I encounter the same strange behaviour. Is the problem fixed in IPNC26 or is there at least some information available how to solve the issue?

Kind regards,

Marc Jüttner

Hi,

Can you please explain the problem you are observing?

PLease share the log and issue details.

Regards,

Raghu

Raghu,

thanks for the quick response! We face the same issue as mentioned above. Based on IPNC15 with most changes from IPNC2.6, we ported the entire software suite to DVSDK4 and notice strange timestamps when streaming audio (which is interrupted in an irregular interval between one and two seconds on the RTSP client-side). The logs show this:

---

<snip>

AUDIO: Create...
Audio Sample File opened
AUDIO_GetSampleRate - CurrentStatus is = 8000
AUDIO : period size = 1000 frames dir = 0
AUDIO : period time = 125000 us dir = 0
Plug PCM: Hardware PCM card 0 'DaVinci DM36x' device 0 subdevice 0
Its setup is:
  stream       : CAPTURE
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 1
  rate         : 8000
  exact rate   : 8000 (8000/1)
  msbits       : 16
  buffer_size  : 16000
  period_size  : 1000
  period_time  : 125000
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 1000
  period_event : 0
  start_threshold  : 1
  stop_threshold   : 16000
  silence_threshold: 0
  silence_size : 0
  boundary     : 2097152000
  appl_ptr     : 0
  hw_ptr       : 0

 AUDIO: Create...DONE
 AUDIO: Start...
 AUDIO: Start...DONE

AUDIO_audioTskRun - AudioBufInfo ready [(1000, 684505365)]
AUDIO_audioTskRun - AudioBufInfo ready [(1000, 684505366)]
AUDIO_audioTskRun - AudioBufInfo ready [(1000, 684505613)]
AUDIO_audioTskRun - AudioBufInfo ready [(1000, 684505614)]
AUDIO_audioTskRun - AudioBufInfo ready [(1000, 684505862)]
AUDIO_audioTskRun - AudioBufInfo ready [(1000, 684505863)]
AUDIO_audioTskRun - AudioBufInfo ready [(1000, 684506111)]
AUDIO_audioTskRun - AudioBufInfo ready [(1000, 684506112)]
AUDIO_audioTskRun - AudioBufInfo ready [(1000, 684506360)]
AUDIO_audioTskRun - AudioBufInfo ready [(1000, 684506361)]
AUDIO_audioTskRun - AudioBufInfo ready [(1000, 684506610)]
AUDIO_audioTskRun - AudioBufInfo ready [(1000, 684506611)]
<snip>
---

As one can see, the timestamps are not at all correct. Regarding the sampling rate, we expect the timestamps to increase by 125ms for each sample block, but we see them increase by ~250ms in the first read and by 0-1 ms in the second read, and so on. Shouldn't they be equidistant?

Our anaylsis turns out that the streaming server comes out of sync due to the malformed timestamps.

So my question is: Is the issue fixed in IPNC2.6, e.g. did we forget something in our porting work? Any hints or explanations?

Thanks in advance,

Marc Jüttner