OpenBSC September 2017

openbsc@lists.osmocom.org

26 participants
54 discussions

[PATCH 1/2] pq_alsa.c: handle output buffer underrun
by Vadim Yanitskiy 02 Sep '17

02 Sep '17

On some systems the ALSA output buffer is pretty big, and if the audio samples are not being passed into the buffer quickly enough, it becomes starved for data, resulting in an error called underrun. Previously, when it happenned, GAPK used to stop processing with the following message (where X is a random number): [+] PQ: Adding ALSA output (dev='default', blk_len=320) [!] pq_execute(): abort, item returned -1 [+] Processed X frames According to the ALSA documentation, the pcm_handle changes its state when the problem happens, and should be recovered using the snd_pcm_prepare() call. This change actually does that. --- src/pq_alsa.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/pq_alsa.c b/src/pq_alsa.c index 9cee426..a3435dd 100644 --- a/src/pq_alsa.c +++ b/src/pq_alsa.c @@ -57,7 +57,15 @@ pq_cb_alsa_output(void *_state, uint8_t *out, const uint8_t *in, unsigned int in struct pq_state_alsa *state = _state; unsigned int num_samples = in_len/2; int rv; + rv = snd_pcm_writei(state->pcm_handle, in, num_samples); + if (rv == -EPIPE) { + /* Recover from buffer underrun */ + snd_pcm_prepare(state->pcm_handle); + /* Send a new sample again */ + rv = snd_pcm_writei(state->pcm_handle, in, num_samples); + } + return rv == num_samples ? 0 : -1; } -- 2.14.1 >From 8f1b0a9bf966cd561b10d2d33c6a47dd02e17dcf Mon Sep 17 00:00:00 2001 From: Vadim Yanitskiy <axilirator(a)gmail.com> Date: Sat, 2 Sep 2017 18:02:45 +0700 Subject: [PATCH 2/2] pq_alsa.c: print error message if device init fails To: openbsc(a)lists.osmocom.org Cc: 246tnt(a)gmail.com, laforge(a)gnumonks.org, axilirator(a)gmail.com --- src/pq_alsa.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/src/pq_alsa.c b/src/pq_alsa.c index a3435dd..cad76ca 100644 --- a/src/pq_alsa.c +++ b/src/pq_alsa.c @@ -85,13 +85,16 @@ pq_queue_alsa_op(struct pq *pq, const char *alsa_dev, unsigned int blk_len, int int rc = -1; state = calloc(1, sizeof(struct pq_state_alsa)); - if (!state) - return -ENOMEM; + if (!state) { + rc = -ENOMEM; + goto out_print; + } rc = snd_pcm_open(&state->pcm_handle, alsa_dev, in_out_n ? SND_PCM_STREAM_CAPTURE : SND_PCM_STREAM_PLAYBACK, 0); if (rc < 0) - return rc; + goto out_print; + state->blk_len = blk_len; rc = snd_pcm_hw_params_malloc(&hw_params); @@ -143,6 +146,9 @@ out_free_par: out_close: snd_pcm_close(state->pcm_handle); free(state); +out_print: + fprintf(stderr, "[!] Couldn't init ALSA device '%s': %s\n", + alsa_dev, snd_strerror(rc)); return rc; } -- 2.14.1

1 0

minor annoyance - file blank on git.osmocom.org
by Keith Whyte 02 Sep '17

02 Sep '17

Does everyone else also see this as an empty file? http://git.osmocom.org/libosmocore/tree/src/codec/gsm690.c The plain text version looks fine. k/

3 2

about merging deletion of checking-value-strings script from libosmocore
by Neels Hofmeyr 02 Sep '17

02 Sep '17

I would have welcomed more patience in merging https://gerrit.osmocom.org/3685, "Use value string check from osmo-ci" in libosmocore. (the commit log of which fails to indicate removal of the script, btw) Moving to the new repositories, I have enough loose ends flapping in the wind, and dropping the script from libosmocore has added yet another distraction, while not being necessary to start using the one from osmo-ci. Max clearly posted "N. B: this should be merged last, after all the repos converted to check script from osmo-ci." -- which is not the case for the new repositores split from openbsc.git. In osmo-msc I have >50 patches waiting to be merged. The timing could hardly have been worse, luckily only a few gerrit builds are affected. Will try to sort out merging of the patches without needing a rebase and >50 rebuilds. Thanks for you attention :) ~N

2 2

RFC: use git-version-gen from gnulib
by Max 01 Sep '17

01 Sep '17

Hi. I'd like to propose to switch from local (unmaintained?) copy of git-version-gen script and use it directly from upstream gnulib package. It's available pretty-much everywhere (including ancient Debian which we support for nightly). It's also available in meta-oe: https://layers.openembedded.org/layerindex/recipe/47365/ It doesn't feel right to use copy-pasted code when we could offload the maintenance work to packaging/dependency tools. What do you think? Please contribute to https://osmocom.org/issues/2467 which I've created to track this RFC. -- Max Suraev <msuraev(a)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

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC September 2017