Hi Benny, thank you very much for reviewing the patch. I am glad to read that you would not mind adding such a functionality to PJSUA(2). And thank you in advance for discussion. I believe I am able to implement it to our satisfaction. See my comments below: Dne 10.3.2014 9:21, Benny Prijono napsal(a): > Hi Vali, > > Thanks for the patch! Yep, the ability to manipulate audio frames from > high level language would be interesting indeed. Yes, I am not the only one. :-) > But I feel that using pipe approach is not the right one. Yes, there's > probably a need to read/write raw files, and from this we can use it to > read/write pipe and have Python open the other side of the pipe, but to > add this mechanism specificly so that Python can read/write audio frames > I feel is not right. Plus the implementation is too low level. All > system dependent code should be in PJLIB. Definitely, the lowest-level implementation should be in PJLIB. Looking to PJLIB file_io_*.c, a function pj_file_fdopen() would be necessary to add. Then pj_file_read/write functions could be used since file descriptors can be converted to ANSI FILEs or Windows HANDLEs which are typedef'ed as pj_oshandle_t. The non/blocking fcntl() stuff should be taken away from fdport.c anyway. Btw. on Windows it is necessary to pass HANDLE instead of int file descriptor from Python to avoid crash. Passing file descriptors may work only if Python, modules and PJ library is linked with the same version of MSVCRT.dll (not static). The pipe implementation is my second attempt. First was the audio callback port (sent the patch earlier) which made callbacks from PJMEDIA thread which caused problems. It might probably work when compiling Python module with SWIG -threads flag. > The approach that I have in mind is to create a media port at PJSUA2 > level, with API to read/write memory location. The operation will be > strictly call only from Python and there's no callback. For example, to > write audio frames in Python: > > while port.needFrames(): > port.write(audio frame) This is nicely simple approach and I am OK with that, but there are few points to sort out: 1. Locking -- there is a race condition between PJMEDIA and calling (e.g. Python) thread. 2. Buffering -- there should always be enough data on sending end to avoid gaps that may harm e.g. speech recognition on the other end. And data on the receiving end also would have to be buffered. 3. Binary data passing mechanism in SWIG. All three points were solved by file/pipe approach. > Best regards, > Benny Thanks for comments and ideas, Vali > > On Thu, Mar 6, 2014 at 4:35 AM, Tom?? Valenta <vali at kamarad.cz > <mailto:vali at kamarad.cz>> wrote: > > Hi Ryan, > > yes, there are no callbacks, no locks so it does not suffer from > deadlocks. The only thing you must be aware off is blocking I/O to > be completed quickly or use non-blocking on UNIX. > > Cheers, > - Vali > > > Dne 5.3.2014 22:28, Ryan Detzel napsal(a): > > Hey Vali, > > Thanks for this, it's great you're adding this to the project. > Will this > solve the issues with deadlocks? > > Thanks > > > On Wed, Mar 5, 2014 at 3:45 PM, Tom?? Valenta <vali at kamarad.cz > <mailto:vali at kamarad.cz> > <mailto:vali at kamarad.cz <mailto:vali at kamarad.cz>>> wrote: > > Hi, > > some time ago I posted a patch that added audio put and get > frame > callback to PJSUA, even to the Python wrapper. It suffered from > deadlocks and occasional crashes (especially with more > calls) so > yesterday I posted a new version that behaves better, but still > deadlocks or crashes might occur. > > I revised the idea of accessing audio frames at a high > level and > created file descriptor media port available in PJSUA, > Python_PJSUA > and PJSUA2, see attached patch. > > Key features: > * It works similarly to audio recorder or player. > * It works with raw data -- no headers or format handling. > * It can read/write from/to a file descriptor or Windows > file handle. > * File descriptor may be virtually everything: file, pipe, > socket etc. > * On UNIX it can operate either in blocking mode or in > non-blocking > mode with buffering. > * It can be used to communicate the data with the same or > different > process. > > Feel free to use it if you find it useful. > Examples are in > pjsip_apps/src/python/samples/____audio_fd.py > and > pjsip_apps/src/swig/python/____audio_fd.py. > > > Benny or other authors, do you think it can be integrated > to the > trunk? I would be helpful and grateful. > > Cheers, > - Vali > > _________________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org <mailto:pjsip at lists.pjsip.org> > <mailto:pjsip at lists.pjsip.org <mailto:pjsip at lists.pjsip.org>> > http://lists.pjsip.org/__mailman/listinfo/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 at lists.pjsip.org <mailto:pjsip at lists.pjsip.org> > http://lists.pjsip.org/__mailman/listinfo/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 at lists.pjsip.org <mailto:pjsip at lists.pjsip.org> > http://lists.pjsip.org/__mailman/listinfo/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 at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >
