Dne 11.3.2014 4:33, Benny Prijono napsal(a): > On Tue, Mar 11, 2014 at 4:07 AM, Tom?? Valenta <vali at kamarad.cz > <mailto:vali at kamarad.cz>> wrote: > > 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. > > > I don't see it with the simple approach above. Remember that this is > strictly polling only by Python application; there's no callback from > the stack to Python app. Yes, but the data set by the new method port.write() would be later processed by PJMEDIA thread. Also the state between port.needFrames() and port.write() therefore might be inconsistent -- which would not be a big problem. And the polling for port.needFrames() would need to be as often as conference bridge frame rate is. Still it could be done in the same polling thread as PJSUA libHandleEvents(). > 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. > > > Yes. > > 3. Binary data passing mechanism in SWIG. > > > I'm sure there's a facility for that. Yes. AFAIK, it must be done per-language (Java, Python, ...) but it is feasible. > All three points were solved by file/pipe approach. > > > I would say the buffering and binary problems would still need to be > solved with the pipe as well. Yes, there must be some buffering with files/pipes in non-blocking mode, but dealing with binary data can be completely avoided. Usually in high-level languages, there are mechanisms to read/write binary files (unlike passing binary parameters) and sources/sinks of such data may also files/pipes or objects that can be written to them (sound card, network, synthesizer, recognizer, filesystem etc.). The data is usually not processed in high-level languages, they are just passed somewhere. > Cheers > Benny I do not claim the pipe (file descriptor) is the only correct way, actually I like the idea port.write(binary_data) binary_data = port.read() better, but there are those issues that have to be resolved: 1. synchronization/locking, 2. polling at least at conference bridge frame rate (possible bottleneck with more calls), 3. binary data representation. Thanks, Vali
