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@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@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@lists.pjsip.org >>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >>> >>> >> >> _______________________________________________ >> Visit our blog: http://blog.pjsip.org >> >> pjsip mailing list >> pjsip@lists.pjsip.org >> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >> > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip@lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >

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@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@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@lists.pjsip.org >>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >>>> >>>> >>>> >>> _______________________________________________ >>> Visit our blog: http://blog.pjsip.org >>> >>> pjsip mailing list >>> pjsip@lists.pjsip.org >>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >>> >>> >> _______________________________________________ >> Visit our blog: http://blog.pjsip.org >> >> pjsip mailing list >> pjsip@lists.pjsip.org >> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >> >> > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip@lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >

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@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@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@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@lists.pjsip.org >>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Visit our blog: http://blog.pjsip.org >>>> >>>> pjsip mailing list >>>> pjsip@lists.pjsip.org >>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >>>> >>>> >>> _______________________________________________ >>> Visit our blog: http://blog.pjsip.org >>> >>> pjsip mailing list >>> pjsip@lists.pjsip.org >>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >>> >>> >> >> _______________________________________________ >> Visit our blog: http://blog.pjsip.org >> >> pjsip mailing list >> pjsip@lists.pjsip.org >> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >> > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip@lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >

Ok thank you for the explanation. It's more clear now. Thank you for all this work. Mathieu Nanang Izzuddin a écrit : > 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@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@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@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@lists.pjsip.org >>>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Visit our blog: http://blog.pjsip.org >>>>> >>>>> pjsip mailing list >>>>> pjsip@lists.pjsip.org >>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Visit our blog: http://blog.pjsip.org >>>> >>>> pjsip mailing list >>>> pjsip@lists.pjsip.org >>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >>>> >>>> >>>> >>> _______________________________________________ >>> Visit our blog: http://blog.pjsip.org >>> >>> pjsip mailing list >>> pjsip@lists.pjsip.org >>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >>> >>> >> _______________________________________________ >> Visit our blog: http://blog.pjsip.org >> >> pjsip mailing list >> pjsip@lists.pjsip.org >> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >> >> > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip@lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >

Hi Benny, I got this message from Thomas: <snip> Hi, I found a bug in the file "os_core_win32.c" The function pj_generate_unique_string() is called before initiializing mutex but needs access to it. You should change it this way: -------------------------------------------------------------------------------- /* Initialize critical section. */ if ((rc=init_mutex(&critical_section_mutex, "pj%p")) != PJ_SUCCESS) return rc; /* Init random seed. */ /* Or probably not. Let application in charge of this */ /* pj_srand( GetCurrentProcessId() ); */ /* Startup GUID. */ guid.ptr = dummy_guid; pj_generate_unique_string( &guid ); </snip> Nearly the latest SVN version. Regards

Thanks Roland, I've fixed this in r1956. But actually you should use guid_win32.c on Windows rather than guid_simple.c, that's why this was not tested. Cheers Benny On Wed, May 14, 2008 at 1:29 PM, Roland Klabunde <roland.klabunde@freenet.de> wrote: > Hi Benny, > > I got this message from Thomas: > > <snip> > Hi, > > I found a bug in the file "os_core_win32.c" > > The function pj_generate_unique_string() is called before initiializing > mutex but needs access to it. > You should change it this way: > > > > -------------------------------------------------------------------------------- > > > /* Initialize critical section. */ > > if ((rc=init_mutex(&critical_section_mutex, "pj%p")) != PJ_SUCCESS) > return rc; > > /* Init random seed. */ > /* Or probably not. Let application in charge of this */ > /* pj_srand( GetCurrentProcessId() ); */ > /* Startup GUID. */ > > guid.ptr = dummy_guid; > pj_generate_unique_string( &guid ); > > </snip> > > Nearly the latest SVN version. > > Regards > > > > > > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip@lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >

Thanks, Benny. Thomas says, he has no choice, he only uses your libs :) He says it is coming from pj_init in os_core_win32.c... Never mind. Regards ----- Original Message ----- From: "Benny Prijono" <bennylp@pjsip.org> To: "pjsip list" <pjsip@lists.pjsip.org> Sent: Thursday, May 15, 2008 11:10 AM Subject: Re: [pjsip] Bug in pj_generate_unique_string() ? > Thanks Roland, I've fixed this in r1956. But actually you should use > guid_win32.c on Windows rather than guid_simple.c, that's why this was > not tested. > > Cheers > Benny > > On Wed, May 14, 2008 at 1:29 PM, Roland Klabunde > <roland.klabunde@freenet.de> wrote: >> Hi Benny, >> >> I got this message from Thomas: >> >> <snip> >> Hi, >> >> I found a bug in the file "os_core_win32.c" >> >> The function pj_generate_unique_string() is called before initiializing >> mutex but needs access to it. >> You should change it this way: >> >> >> >> -------------------------------------------------------------------------------- >> >> >> /* Initialize critical section. */ >> >> if ((rc=init_mutex(&critical_section_mutex, "pj%p")) != PJ_SUCCESS) >> return rc; >> >> /* Init random seed. */ >> /* Or probably not. Let application in charge of this */ >> /* pj_srand( GetCurrentProcessId() ); */ >> /* Startup GUID. */ >> >> guid.ptr = dummy_guid; >> pj_generate_unique_string( &guid ); >> >> </snip> >> >> Nearly the latest SVN version. >> >> Regards >> >> >> >> >> >> >> >> _______________________________________________ >> Visit our blog: http://blog.pjsip.org >> >> pjsip mailing list >> pjsip@lists.pjsip.org >> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >> > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip@lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >

On Thu, May 15, 2008 at 10:49 AM, Roland Klabunde <roland.klabunde@freenet.de> wrote: > Thanks, Benny. Thomas says, he has no choice, he only uses your libs :) He > says it is coming from pj_init in os_core_win32.c... > Ah I see. You're right, it seems that the WinCE project uses guid_simple.c. Sorry I was talking rubbish. Cheers Benny > Never mind. > > Regards > > > > ----- Original Message ----- > From: "Benny Prijono" <bennylp@pjsip.org> > To: "pjsip list" <pjsip@lists.pjsip.org> > Sent: Thursday, May 15, 2008 11:10 AM > Subject: Re: [pjsip] Bug in pj_generate_unique_string() ? > > > > Thanks Roland, I've fixed this in r1956. But actually you should use > > guid_win32.c on Windows rather than guid_simple.c, that's why this was > > not tested. > > > > Cheers > > Benny > > > > On Wed, May 14, 2008 at 1:29 PM, Roland Klabunde > > <roland.klabunde@freenet.de> wrote: > >> Hi Benny, > >> > >> I got this message from Thomas: > >> > >> <snip> > >> Hi, > >> > >> I found a bug in the file "os_core_win32.c" > >> > >> The function pj_generate_unique_string() is called before initiializing > >> mutex but needs access to it. > >> You should change it this way: > >> > >> > >> > >> -------------------------------------------------------------------------------- > >> > >> > >> /* Initialize critical section. */ > >> > >> if ((rc=init_mutex(&critical_section_mutex, "pj%p")) != PJ_SUCCESS) > >> return rc; > >> > >> /* Init random seed. */ > >> /* Or probably not. Let application in charge of this */ > >> /* pj_srand( GetCurrentProcessId() ); */ > >> /* Startup GUID. */ > >> > >> guid.ptr = dummy_guid; > >> pj_generate_unique_string( &guid ); > >> > >> </snip> > >> > >> Nearly the latest SVN version. > >> > >> Regards > >> > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> Visit our blog: http://blog.pjsip.org > >> > >> pjsip mailing list > >> pjsip@lists.pjsip.org > >> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > >> > > > > _______________________________________________ > > Visit our blog: http://blog.pjsip.org > > > > pjsip mailing list > > pjsip@lists.pjsip.org > > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip@lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >