Possible issue regarding resample_port

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi

This is my first post in the lists. I think I may have stumbled upon a
problem in resample_port.c... or maybe upon a problem in my
understanding of the libs :). I am using pjsip 1.14, but as long as I
know this problem should reproduce in 2.0

I am building an application that, at some point, joins the "master
ports" of two conference bridges with different clock rate. No audio
devs are involved, as the app just mixes media and relies streams.  I
acomplish joining the bridges "master ports" by using a (proper and
clocked) master port and, optionally, a resample port if needed. The
general schema goes like this


                            conf_brifge
                                                     conf_brifge
streams <-> [ slots | "master port " ] <-> master_port <->
resample_port <-> [  "master port " | slots ] <-> streams



The problem arises when master_port calls put_frame on the
resample_port, and ultimately on the conf_bridge *before* audio frames
are available ( frame.type = PJMEDIA_FRAME_TYPE_NONE). In this
situation, an assertion on the frame size fails when calling
conference bridge's put_frame()

conference.c 2060   PJ_ASSERT_RETURN (frame->size ==
conf->samples_per_frame * conf_bits_per_sample /8)


This is because when the frame type is other than
PJMEDIA_FRAME_TYPE_AUDIO, the resample port does not run its internal
resampler to process the acquired frame, passing it through untouched.
So if the frame sizes of the ports adapted by the resample port differ
(which I assume is usual), the conference bridges at each side will
complain, even if the frame carries no audio (PJMEDIA_FRAME_TYPE_NONE)
.


My question are:

a) Is this a real issue, or am I missing something ( using the two
bridges has to do with the app architecture and components)
b) If so, which is the best way to fix it?


Regarding b, my working solution is returning the a frame with the
appropriate type (NONE) and size pointing to the very same buffer the
resample_port uses when it really runs the resampler on incoming
frame. My main concern are the possible implications of this. Should I
allocate another buffer, just to be used in this situation? Is there a
better way to fix the problem?


Thanks in advance

Pablo



[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux