[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Linphone-developers] MediaStreamer/Alsa misconfiguration on an Imx6

From: bagamarco .
Subject: Re: [Linphone-developers] MediaStreamer/Alsa misconfiguration on an Imx6 based product
Date: Fri, 9 Feb 2018 13:52:52 +0100

Hi Thomas,

you should try to apply patches from my first mail: "[Mail 1/3][PATCH] mediastreamer2: audio quality, tool/mediastreamer feature and minor changes"

Also, it is not necessary change ALSA_PERIOD_SIZE and ALSA_PERIODS. You could change period_time, buffer_time, period_size, buffer_size parameter in /etc/asound.conf (probably you have to try and retry and retry variuos configuration... after many tests I reached the goal)
Eg. I created a custom capture card with:
        period_time 0
        period_size 480
and a custom playback card with:
        period_time 0
        buffer_time 0
        period_size 2048
        buffer_size 32768

This configuration permits to reduce capture latency but avoid EAGAIN.
Also I had to enabled ALSA_THREADED_VERSION with new CMake option interface.

Actually I have no more problems with ulaw (pcmu and friends 8bit@8KHz) and opus (16bit@48KHz).

I hope these information could help.

2018-02-08 11:26 GMT+01:00 Ерохин Андрей <address@hidden>:
Hello Thomas!
I can see from attached logs that you are already using low rate codec and, as you mentioned, no "alsa_can_read fixup" message appears either. So this is not what I was talking about and I can not provide much help to you.
But this repeated message looks suspicious:
ortp-message-sound/wall clock skew is average=302.626768 ms
This value constantly increases throughout the log, and it looks like the soundcard is producing/consuming samples too slow? Or at least makes mediastreamer thinks so.
In later case you may try to uncomment
in the beginning of alsa.c, looks like timing correction will not be performed by mediastreamer in this case.
In former case the problem may be in platform driver.

08.02.2018, 12:06, "Thomas Dalmayrac" <address@hidden>:

Hi Андрей !

Thanks for sharing your experience. The idea is excellent, we had a look yesturday afternoon at all the things you talked about. I tried  I can't see the linphone/alsa message *** alsa_can_read fixup, trying to recover.

I tried increasing ALSA_PERIOD_SIZE to 1024 and let the ALSA_PERIODS to 8, the result is a little bit better but still echoed somtimes (16' ok | 19' echo/not ok | 2"2' ok | 15' echo/not ok...) Here is the record of the call (made with a poor mic, sorry) :

I attached the timestamped logs, you can have a look around [08/02/18 - 09:39:57:048], it corresponds to 16' of call where the first audio problem occurs.

Again thanks for your help !


Le 07/02/2018 à 13:53, Ерохин Андрей a écrit :
Hello sir!
I was working with linphone on iMX6 using kernel 3.0.35, codec was aic32. This is probably not 1to1 your case, but just in case:
Sometimes IRQ latency in that kernel was about 200ms which caused mediastreamer to reset aic32 time after time. Do you see messages like following in linphone output?
*** alsa_can_read fixup, trying to recover
It may be caused by IRQ latency. There's not much ways to workaround this in mediastreamer. Try using low sampleraterate codecs or increasing ALSA_PERIOD_SIZE even more. Or do it on system level if you have root access: change CPU affinity of linphone and sDMA IRQ (in case when your I2S driver uses sDMA), move them away from CPU0.

Linphone-developers mailing list

Thomas Dalmayrac
Ingénieur Développement - IHM
3 rue de Bavière
44240 La chapelle sur Erdre
Tel : (+33) 2 51 13 54 66

Linphone-developers mailing list

Linphone-developers mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]