This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Max msuraev at sysmocom.deSure. I'm working on DTX support in OsmoBTS. The BSC side for DTX uplink (phone skipping some frames when there#s no voice) is pretty much ready. I've tested with nanobts and it works fine. When I try it with osmobts there's audible delay in voice after the talking is resumed after pause (dtx kicked in). This delay (and following distortion which I guess is cause by codec trying to "catch-up") appear regardless of the channel/codec (fr, hr, amr...). When I compare graphs in wireshark's rtp analysis I can see that in osmobts (unlike in nanobts) there are multiple spikes in forward diff (difference between actual arrival time and time in rtp packet). This and the comment in src/common/l1sap.c:633 suggest that we have to account for extra delay by changing the way we adjust rtp_socket->rx_user_ts. Right now both when sending and receiving with osmo_rtp_* we increment rx_user_ts and tx_timestamp in steps of 160. Both end-up as "userts" parameter to oRTP's rtp_session_sendm_with_ts <http://www.antisip.com/doc/ortp/rtpsession_8h.html#fda0872c335c06a86a45ca4591a8b7ee>()/rtp_session_recvm_with_ts() <http://www.antisip.com/doc/ortp/rtpsession_8h.html#7df1261d3eeaf10d283ba4ac34e2388d>. So it's not exactly timestamp in RTP, it's relative to 1st packet - the oRTP is supposed to take care of syncing it with actual timestamp. On 06/02/2016 06:11 AM, Alexander Chemeris wrote: > > Hi Max, > > Could you explain what are you trying to solve? I may be able to help, > but I don't really understand what you're trying to achieve. > > Your conversion to ms is wrong. Narrowband codecs have 8000 > samplerate, so with 160 samples in a packet, packet duration is > 160/8000 = 20ms. But I don't see why do you need this conversion? I > would think that working with samples is a better approach, because > you operate with integers and don't have issues associated with > floating numbers (rounding issues, comparison requires epsilon, etc). > > Please excuse typos. Written with a touchscreen keyboard. > > -- > Regards, > Alexander Chemeris > CEO Fairwaves, Inc. > https://fairwaves.co > > On Jun 1, 2016 6:19 PM, "Max" <msuraev at sysmocom.de > <mailto:msuraev at sysmocom.de>> wrote: > > Hi. > > Right now in osmobts when sending/receiving frames with osmo_rtp_* > it's > assumed that no frame is lost and timestamp is always advanced in > 160ms > steps. In practice (especially when DTX is in place) frames do get > lost > so we have to adjust the step to compensate. > > I've tried to do it as follows: > - store frame number of last used frame on receiving/sending > - check how far current frame number from old one > - convert frame number delta to ms: each frame is 4.615 ms long > - if delta in ms is bigger than default 160 than use it > > However the result sound not much better than using hardcoded value > which suggest that I might be doing FN -> ms conversion (or smth else) > wrong. Any ideas/advices? > > -- > Max Suraev <msuraev at sysmocom.de <mailto:msuraev at sysmocom.de>> > http://www.sysmocom.de/ > ======================================================================= > * sysmocom - systems for mobile communications GmbH > * Alt-Moabit 93 > * 10559 Berlin, Germany > * Sitz / Registered office: Berlin, HRB 134158 B > * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald > Welte > -- Max Suraev <msuraev at sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte