On Fri, Feb 19, 2010 at 9:54 PM, Governa <affqlixo at gmail.com> wrote: > This is exactly what I was trying to do. I'm doing it like this: > Connect: > pjmedia_conf_connect_port(conf, rtp_slot, 0, 0); > pjmedia_conf_connect_port(conf, 0, rtp_slot, 0); > Disconnect: > pjmedia_conf_disconnect_port(conf, rtp_slot, 0); > pjmedia_conf_disconnect_port(conf, 0, rtp_slot); > Okay. > I have 3 sound devices, so I have 3 conference bridges in the > receiver's side and 3 in the sender's side. In the receiver side I > don't really need the conference bridge but it is not causing any > problems either and its easier to initialize all the streams in the > same way. I have to say that having 3 conference bridges is unusual, but if it works for you then I guess it's fine, as long as you understand that the bridge has some overheads in both processing and latency. If you never need to mix anything, you may want to consider using the switchboard instead, which has lower overhead and offers the same API as conf bridge. > From what I've understood of the documentation[*]?the snd_port is in > slot 0, and there should be only one snd_port, is that right? > Yes, more or less (to be precise, slot 0 is for the "thing" that calls get/put_frame to the bridge). > [*] http://www.pjsip.org/pjmedia/docs/html/group__PJMEDIA__CONF.htm#gfcac2438fa076eb94571de14e51835cb > >> >> > When I run the application with gprof enabled, I see get_frame and put_frame >> > as the great consumers of CPU power. >> >> No surprise here, since that's where most of the works are done, >> including encoding/decoding audio. So as I said above, it's important >> to disconnect the mic from the streams when you're not transmitting, >> to prevent unnecessary get/put_frame calls. >> > > Yes, I really expected to have this functions as the bottlenecks ?when > I'm streaming. The strange thing is that they are running even without > streaming (after pausing the RTP stream with > pjmedia_stream_pause(sound_fd[fd]->rtp_stream, > PJMEDIA_DIR_ENCODING_DECODING);). I've checked if the stream was > really stopped with wireshark and there is nothing in the network. > Rather than calling pjmedia_stream_pause() to stop the stream, you should disconnect the TX direction to the stream in the conference bridge instead. Without this, the stream put_frame() will still be called by the bridge. >> What codec are you using? >> > > L16/16000/1, but see below... > Ok. >> > I have one conference brigde, so that I can connect wav_players and >> > recorders, so my first solution was to try to disconnect everything from the >> > conference brigde. >> > I tried disconnecting the snd_port also, but no difference in performance >> > with this step. I've searched a bit and found?pjmedia_aud_stream_stop >> >> What do you mean by disconnecting the snd_port? Did you mean >> snd_port_disconnect or conf_disconnect_port? >> >> Disconnecting the sound port with snd_port_disconnect should >> definitely make a difference, since this would prevent the conference >> bridge from running. If you don't see any different, then either the >> CPU hog is not in the bridge, or there's some mistake in your >> procedure. >> > > I disconnect the snd_port from the conference with: > pjmedia_snd_port_disconnect(snd_port); > > But this is not enought to stop it. I've profiled the program > again(now with callgrind) and the CPU seems to go to ALSA. > During the profiling, I've not streamed anyting, only opened the > streams and paused then with > conf_disconnect/snd_port_disconnect/pjmedia_stream_pause. > That's pretty much expected. If you disconnect the sound port, then everything else will not run, but the sound device is still running, getting/putting audio frames from/to microphone/speaker as usual. The audio frames would be discarded of course, since the sound port is not connected to any other ports. > Since the bridge is not connecting the RTP stream and the snd_port and > there are no packets in the network, I assume the RTP is really > paused. And since the profiling pointed to ALSA, I assume the problem > is in snd_port. Am I missing something? > That's correct, RTP is paused but ALSA is still running. > I can use some tricks in ALSA configuration to speed up the things, > but I really want to stop requesting data from the system when I don't > need it. Is this possible with PJ or will I have to search in > portaudio? > If you really want to stop all the media flows, then you'd need to stop the sound device. By the way, we have a new, native pjmedia_audiodev ALSA device implementation in current SVN trunk (implemented by ticket #1016), please have a try, as this implementation should be better suited for embedded devices (it's simpler and smaller). Cheers Benny
