[pjsip] Segmentation fault in resample_port.c

Nanang Izzuddin nanang at pjsip.org
Wed May 14 05:07:05 EDT 2008


Glad to hear your feedback!

In this case, when sound device/resampler asks for audio frame to the
conference bridge, non-audio frame type is returned by conference
bridge since no port is connected to sound device/resample port yet
(no transmitter).

Regards,
nanang


2008/5/14 Mathieu Monney <zittix_all at xwaves.net>:
> Well now it's working :-) ! Thank you very much.
>
> Just to understand more deeply, I'm using only audio frame so the
> resampling of non-audio sample should not occurs. Why is it occurring ?
>
> Cheers,
>
> Mathieu
>
> Nanang Izzuddin a écrit :
>> Sorry, just recheck this and realized this is bug of resample port,
>> when frame from the downport is non-audio type, the resample port copy
>> the frame returned from downport carelessly. It's just been fixed and
>> committed into the latest SVN (r1955).
>>
>> Thanks for the report!
>>
>> Regards,
>> nanang
>>
>>
>> 2008/5/14 Mathieu Monney <zittix_all at xwaves.net>:
>>
>>> Thank you for your answer.
>>>
>>> Well I'm working with mono-audio. I'm using the stock PJSUA app with my
>>> audio driver. So I think it's mono audio.
>>>
>>> I have just tried with the latest SVN version and it gives me exactly
>>> the same error. I actually found the bug. I'm only allowing to open the
>>> device at 8000 Hz. But PJSUA want a clock rate of 16000 Hz (don't know
>>> why, seems to be config related). So there should be up/down sampling of
>>> factor 2. When I'm playing audio, PJSUA need to downsample the audio to
>>> 8000 Hz. The frame size (mono or stereo it doesn't matter) should half
>>> the frame size of the original audio data. The bug is here.
>>>
>>> In resample_port.c of the latest SVN version, in function
>>> resample_get_frame(), there is the following line:
>>>
>>> tmp_frame.size = rport->dn_port->info.bytes_per_frame;
>>>
>>> As I understand it tells that the size of the frame is equal to the
>>> master conf port frame size. Actually the master conf port sampling rate
>>> is 16000 which twice the frame size of my audio driver. After that, the
>>> line:
>>>
>>> status = pjmedia_port_get_frame( rport->dn_port, &tmp_frame);
>>>
>>> gets the frame with the wrong size (it doesn't seg fault here).
>>>
>>> and then the down sampling process is done and the segfault appear. So I
>>> think (I'm sure I'm missing something but what ?) there is confusion in
>>> frame size in the down sampling stuffs.
>>>
>>> If I allocate a buffer of twice the frame size in my audio driver it fix
>>> the seg fault but then the audio is corrupt..
>>>
>>> Any clues appreciated :-)!
>>>
>>> Cheers,
>>>
>>> Mathieu
>>>
>>> Benny Prijono a écrit :
>>>
>>>> On Tue, May 13, 2008 at 12:57 PM, Mathieu Monney <zittix_all at xwaves.net> wrote:
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>>  I'm trying to develop a gstreamer audio back-end for PJSIP but I get a
>>>>>  seg fault in the resampling stuffs When I use the rec/play examples my
>>>>>  audio driver works just fine but when I'm using pjsua it seg fault.
>>>>>
>>>>>
>>>> Yep. The rec/play samples don't use resample.
>>>>
>>>>
>>>>
>>>>>  I'm using PJSIP release 0.8.0. The seg fault comes from the fact that in
>>>>>  the resampling port the frame size in byte is equal to twice the frame
>>>>>  size in my audio driver.
>>>>>
>>>>>  In the resample_get_frame() function in file resample_port.c at line 177
>>>>>  the size is equal to 320 (for my case). In my audio driver I compute the
>>>>>  frame size as following:
>>>>>  samples_per_frame*(bits_per_sample>>3)*channel_count
>>>>>
>>>>>  which gives half the value above. But my computation seems correct. Is a
>>>>>  bug or am I missing something ?
>>>>>
>>>>>
>>>>>
>>>> Well which one is correct is indeed the question. Are you working with
>>>> non-mono audio?
>>>>
>>>> In version 0.8 and older, the convention about samples_per_frame value
>>>> was not clear when channel_count is non-mono. That is, say if the
>>>> audio is stereo, does the samples_per_frame value represent the
>>>> combined/2-channels frame length, or does it only represent the size
>>>> of the mono frame. If I recall correctly some objects in pjmedia used
>>>> different convention hence probably what you saw.
>>>>
>>>> The convention that has been established now (in SVN version) is the
>>>> samples_per_frame represents the total length of the frame, that is
>>>> it's equal to mono_count*channel_count (Nanang can correct me if I'm
>>>> wrong). So because of this you may be better working with the SVN
>>>> version instead.
>>>>
>>>> Cheers
>>>>  Benny
>>>>
>>>>
>>>>
>>>>>  Thank you.
>>>>>
>>>>>  Mathieu
>>>>>
>>>>>  _______________________________________________
>>>>>  Visit our blog: http://blog.pjsip.org
>>>>>
>>>>>  pjsip mailing list
>>>>>  pjsip at lists.pjsip.org
>>>>>  http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Visit our blog: http://blog.pjsip.org
>>>>
>>>> pjsip mailing list
>>>> pjsip at lists.pjsip.org
>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>>
>>>>
>>> _______________________________________________
>>> Visit our blog: http://blog.pjsip.org
>>>
>>> pjsip mailing list
>>> pjsip at lists.pjsip.org
>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>
>>>
>>
>> _______________________________________________
>> Visit our blog: http://blog.pjsip.org
>>
>> pjsip mailing list
>> pjsip at lists.pjsip.org
>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>
>
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>




More information about the pjsip mailing list