Avoid panics caused by deleting the VAS uplink stream before all buffers emptied (Known Issue)

Comments

(no comments yet)

Log in or Join to leave comments.

Premature deletion of a VoIP Audio Service (VAS) uplink stream (CVoIPAudioUplinkStream) instance may cause a panic.

Article Metadata

---

Code Example

Source file: Media:VoIPTestApp.zip

---

Tested with

Devices(s): Tested on Nokia 5630,
Nokia 5800

---

Compatibility

Platform(s): S60 3rd Edition, FP2
S60 5th Edition

---

Article

Keywords: CVoIPAudioUplinkStream, MVoIPUplinkObserver

Created: User:Kbwiki (20 Oct 2010)

Last edited: hamishwillee (12 Mar 2012)

Detailed description

After calling CVoIPAudioUplinkStream::Stop(), a VAS client should still be prepared to receive MVoIPUplinkObserver::EmptyBuffer() callbacks as VAS ensures that all recorded (and buffered) data is delivered.

Deleting the uplink stream immediately after calling Stop() causes a VoIPUplinkThreadMmfDevSoundProxy 1 panic.

Solution

A VAS client should proceed to delete the uplink stream only after receiving a MVoIPUplinkObserver::Event() callback with either KUplinkClosed or KUplinkError as an event type.

Additionally, after calling CVoIPAudioUplinkStream::Stop(), a client should not longer call CVoIPAudioUplinkStream::BufferEmptied() in response to MVoIPUplinkObserver::EmptyBuffer() callbacks.

The VoIPTestApp example application takes care of this by maintaining uplink/downlink state variables and only calling BufferEmptied() if the uplink is in 'streaming' state.