hi, i experienced audio glitches while another phone does location updating: <0001> gsm_04_08.c:191 (bts 1 trx 0 ts 0 pd 05) Sending 0x18 to MS. <0008> abis_rsl.c:1027 [262421104120913] MEASUREMENT RESULT NR=0 RXL-FULL-ul=-110dBm RXL-SUB-ul=-47dBm R Q-FULL-ul=0 RXQ-SUB-ul=0 BS_POWER=0 L1_MS_PWR= 0dBm L1_FPC=0 L1_TA=0 NOT VALID NUM_NEIGH=0 <0003> bsc_api.c:615 CLASSMARK CHANGE CM2(len=3) CM3(len=4) dbi access time 95ms Stalled 96ms <0008> abis_rsl.c:1027 [262421104120913] MEASUREMENT RESULT NR=1 RXL-FULL-ul=-66dBm RXL-SUB-ul=-47dBm RX -FULL-ul=0 RXQ-SUB-ul=0 BS_POWER=0 L1_MS_PWR= 0dBm L1_FPC=0 L1_TA=0 RXL-FULL-dl=-47dBm RXL-SUB-dl=-47dB RXQ-FULL-dl=0 RXQ-SUB-dl=0 NUM_NEIGH=7 dbi access time 50ms dbi access time 0ms dbi access time 49ms dbi access time 58ms dbi access time 83ms dbi access time 0ms dbi access time 0ms dbi access time 0ms dbi access time 72ms <0003> gsm_04_08_utils.c:315 TX CIPHERING MODE CMD Stalled 319ms <0008> abis_rsl.c:1027 [262421104120913] MEASUREMENT RESULT NR=2 RXL-FULL-ul=-65dBm RXL-SUB-ul=-47dBm RX -FULL-ul=0 RXQ-SUB-ul=0 BS_POWER=0 L1_MS_PWR= 0dBm L1_FPC=0 L1_TA=0 RXL-FULL-dl=-47dBm RXL-SUB-dl=-47dB RXQ-FULL-dl=0 RXQ-SUB-dl=0 NUM_NEIGH=7 <0003> osmo_msc.c:105 CIPHERING MODE COMPLETE dbi access time 0ms dbi access time 69ms <0001> gsm_04_08.c:191 (bts 1 trx 0 ts 0 pd 05) Sending 0x02 to MS. <0001> gsm_04_08.c:191 (bts 1 trx 0 ts 0 pd 05) Sending 0x32 to MS. dbi access time 66ms dbi access time 0ms dbi access time 0ms <0003> gsm_04_08.c:1249 TX APPLICATION INFO id=0x00, len=4 <0001> gsm_04_08.c:191 (bts 1 trx 0 ts 0 pd 06) Sending 0x38 to MS. dbi access time 0ms Stalled 140ms the total time that openbsc was stalling is 555ms in this case. there are only 4 subscribers in hlr and counter writing is disabled. is there any trick to make database access faster? speeding up the db access does not solve the problem. an async db access is one solution, but there is other code at openbsc that might require some time. (e.g. handling of many measurement reports) one solution is to have an own thread for the audio processing. this thread must access different interfaces independently from the rest of the openbsc code: - RTP sockets - MNCC socket - TRAU sockets of E1 timeslots MNCC socket could be split into two sockets: one for signalling, one for audio traffic. this way it is not required to use queues and signals between main thread and audio thread. a problem in case of multithreading is osmo_select_main(). it uses global list of file descriptors and global rb-tree for timers. one solution would be having multiple lists and trees for each thread id. this way it is not required to change timer and file descriptor api. another solution could be a seperate process, which handles audio only. i don't really like a sepeate process, since it requires some interface to openbsc and makes everything more complex. even though i don't like threads, multithreading seems to be the best solution to me at the moment. was there any effort to solve the problem or to handle audio? are there any suggestions about it? regard, andreas