Hi, I'm trying to get the speex mode of jVoiceBridge to work with pjsip on the iphone/simulator. So far I was a successful in that I get audio, but it's pretty chopped up. Current status is: - jVoicebridge (which uses jspeex) comes with an jspeex-based softphone that works with it - jVoicebridge with PCMU/8000 works just fine with the iphone, but bandwidth is too high for mobile I hacked a few extra log statements into the source (jbuf.c and stream.c) and tracing the calls shows this: PCMU: 11:39:17.610 strm0x887a974 RX: seq=8448 payload=0 len=160 count=2 11:39:17.610 strm0x887a974 Checking frame #66: eff=2 disc=0 orig:64 seq_delta:66 11:39:17.610 strm0x887a974 Checking frame #67: eff=3 disc=0 orig:64 seq_delta:67 11:39:17.630 strm0x887a974 RX: seq=8704 payload=0 len=160 count=2 11:39:17.630 strm0x887a974 Checking frame #68: eff=2 disc=0 orig:66 seq_delta:68 11:39:17.630 strm0x887a974 Checking frame #69: eff=3 disc=0 orig:66 seq_delta:69 11:39:17.651 strm0x887a974 RX: seq=8960 payload=0 len=160 count=2 11:39:17.651 strm0x887a974 Checking frame #70: eff=2 disc=0 orig:68 seq_delta:70 11:39:17.651 strm0x887a974 Checking frame #71: eff=3 disc=0 orig:68 seq_delta:71 Basically, one 160-byte frame comes in and gets split into two frames for the jitter buffer. When I use speex, I get: 12:26:09.847 strm0x8843b74 RX: seq=10240 payload=102 len=28 count=1 12:26:09.847 strm0x8843b74 Checking frame #80: eff=18 disc=6 orig:55 seq_delta:4 12:26:09.847 strm0x8843b74 Discarding frame #80: eff=18 disc=6 orig:55 seq_delta:4 12:26:09.858 strm0x8843b74 Frame lost, recovered! 12:26:09.868 strm0x8843b74 RX: seq=10496 payload=102 len=28 count=1 12:26:09.868 strm0x8843b74 Checking frame #82: eff=17 disc=6 orig:58 seq_delta:2 12:26:09.881 strm0x8843b74 Jitter buffer starts returning normal frames (after 1 empty/lost) 12:26:09.889 strm0x8843b74 RX: seq=10752 payload=102 len=28 count=1 12:26:09.889 strm0x8843b74 Checking frame #84: eff=18 disc=6 orig:59 seq_delta:4 12:26:09.889 strm0x8843b74 Discarding frame #84: eff=18 disc=6 orig:59 seq_delta:4 12:26:09.905 strm0x8843b74 Frame lost, recovered! So it looks like I only get every other frame instead of two into the buffer. Also, the count in Enabling and adding logging to speex shows: 12:26:10.268 strm0x8843b74 RX: seq=15616 payload=102 len=15 count=1 12:26:10.268 strm0x8843b74 Checking frame #122: eff=17 disc=6 orig:98 seq_delta:2 12:26:10.276 speex_codec.c Decode Speex 320 12:26:10.276 strm0x8843b74 Jitter buffer starts returning normal frames (after 2 empty/lost) 12:26:10.289 speex_get_next Control bits: 4 at 5 12:26:10.289 speex_get_next Submode 4: 220 bits 12:26:10.289 speex_codec.c Parsing Speex frames: 1 12:26:10.289 strm0x8843b74 RX: seq=15872 payload=102 len=28 count=1 12:26:10.289 strm0x8843b74 Checking frame #124: eff=18 disc=6 orig:99 seq_delta:4 12:26:10.289 strm0x8843b74 Discarding frame #124: eff=18 disc=6 orig:99 seq_delta:4 12:26:10.299 strm0x8843b74 Frame lost, recovered! 12:26:10.310 speex_get_next Control bits: 3 at 5 12:26:10.310 speex_get_next Submode 3: 160 bits 12:26:10.310 speex_codec.c Parsing Speex frames: 1 12:26:10.310 strm0x8843b74 RX: seq=16128 payload=102 len=20 count=1 12:26:10.310 strm0x8843b74 Checking frame #126: eff=17 disc=6 orig:102 seq_delta:2 12:26:10.311 speex_get_next Control bits: 5 at 5 12:26:10.311 speex_get_next Submode 5: 300 bits 12:26:10.311 speex_codec.c Parsing Speex frames: 1 12:26:10.311 strm0x8843b74 RX: seq=16384 payload=102 len=38 count=1 12:26:10.311 strm0x8843b74 Checking frame #128: eff=19 disc=6 orig:102 seq_delta:4 12:26:10.311 strm0x8843b74 Discarding frame #128: eff=19 disc=6 orig:102 seq_delta:4 12:26:10.333 speex_get_next Control bits: 6 at 5 12:26:10.333 speex_get_next Submode 6: 364 bits 12:26:10.333 speex_codec.c Parsing Speex frames: 1 So, now if I now change: ext_seq = (unsigned)(frames[i].timestamp.u64 / ts_span); to ext_seq = (unsigned)(frames[i].timestamp.u64 / ts_span / (frames[i].size > 80 ? 1: 2)); (which is a hack, but I only use PCMU/8000 and speex/8000) to accomodate for the fact that we get only one 160 frame instead of two 80 byte frames, the log looks like: 13:18:45.973 strm0x8884f74 RX: seq=7939 payload=102 len=6 count=2 13:18:45.973 strm0x8884f74 Checking frame #3014: eff=1 disc=0 orig:3013 seq_delta:3014 13:18:45.973 strm0x8884f74 Checking frame #3014: eff=2 disc=0 orig:3013 seq_delta:3014 13:18:45.994 strm0x8884f74 RX: seq=8195 payload=102 len=6 count=2 13:18:45.994 strm0x8884f74 Checking frame #3015: eff=1 disc=0 orig:3014 seq_delta:3015 13:18:45.994 strm0x8884f74 Checking frame #3015: eff=2 disc=0 orig:3014 seq_delta:3015 13:18:46.014 strm0x8884f74 RX: seq=8451 payload=102 len=6 count=2 13:18:46.014 strm0x8884f74 Checking frame #3016: eff=0 disc=0 orig:3016 seq_delta:3016 13:18:46.014 strm0x8884f74 Checking frame #3016: eff=1 disc=0 orig:3016 seq_delta:3016 which in turn looks like the PCMU above and the sound is (more or less) OK. So it looks like the jitter-buffer doesn't take the nature of speex packets into account? But then again, this could totally be a red herring and I'm running around chasing my own tail... It would be great if someone could help me out or at least point me into the right direction, because I'm not *really* that proficient with all this audio/coder stuff :( Cheers, Anjo
