Kernel 5.1: Audio hanging on Alsaloop Poll

Hello,

While working with the dragonboard I ran into an interesting issue with the audio pipeline using alsaloop! I believe this might be an issue with alsa that alsaloop is showing.

(Yocto build tested on thud and warrior)
Kernel: 5.1
Branch: release/db845c/qcomlt-5.1
Command: alsaloop -C hw:0,1 -P hw:0,0 -U -S 0 -l 2400 -v -v -v -v -v -v -v -v -v -v -v -v -v -v -v -v
(I used all the verbose lines to show all the data getting passed through)

This issue occurs when running alsaloop. The issue is that at any given moment alsaloop will hang up and start skipping and it never seems to recover. I was able to make this issue happen by rapidly restarting alsaloop (closing alsaloop using ctrl+c then restarting alsaloop by using the up arrow and restarting it). I am unsure If it is the same issue but it gives me the same errors.

I ran alsaloop on a few dragonboards and I have been able to see it happen more then once but in each case it happened at a random time and on a few of the boards after running a few days it never happened.

The verbose output I receive is "

playback hw:0,0/capture hw:0,1: pollfds handle
playback hw:0,0: delay 1368 / 8192 / 0
capture hw:0,1: delay 1008 / 8192 / 8
playback hw:0,0/capture hw:0,1: prevents = 0x4, crevents = 0x0
playback hw:0,0: end delay 2372 / 8192 / 0
capture hw:0,1: end delay 4 / 8192 / 8
playback hw:0,0/capture hw:0,1: processing time 134us
pool took 21477us
playback hw:0,0/capture hw:0,1: pollfds handle
playback hw:0,0: delay 1336 / 8192 / 0
capture hw:0,1: delay 1040 / 8192 / 8
playback hw:0,0/capture hw:0,1: prevents = 0x4, crevents = 0x1
playback hw:0,0: end delay 2368 / 8192 / 0
capture hw:0,1: end delay 8 / 8192 / 8
playback hw:0,0/capture hw:0,1: processing time 164us
pool took 21081us
playback hw:0,0/capture hw:0,1: pollfds handle
playback hw:0,0: delay 1352 / 8192 / 0
capture hw:0,1: delay 1024 / 8192 / 8
playback hw:0,0/capture hw:0,1: prevents = 0x4, crevents = 0x1
playback hw:0,0: end delay 2372 / 8192 / 0
capture hw:0,1: end delay 8 / 8192 / 8
playback hw:0,0/capture hw:0,1: processing time 139us
pool took 20771us
playback hw:0,0/capture hw:0,1: pollfds handle
playback hw:0,0: delay 1368 / 8192 / 0
capture hw:0,1: delay 1008 / 8192 / 8
playback hw:0,0/capture hw:0,1: prevents = 0x4, crevents = 0x0
playback hw:0,0: end delay 2372 / 8192 / 0
capture hw:0,1: end delay 4 / 8192 / 8
playback hw:0,0/capture hw:0,1: processing time 128us
^Cpool took 3155535474us

"
You can see that it hung up and when I exited, alsaloop returned “pool took 3155535474us”. The pool value in the code traces back to a poll function in alsaloop.c (and that seems to call back to the kernel). That error is coming from alsaloop but I was unsure so I went into my yocto defconfig. I turned on alsa debugging (SND_PCM_XRUN_DEBUG [=y]) with that on I echoed 29 into “/proc/asound/card0/pcm0p/xrun_debug” I received this in my dmesg "

ALSA: PCM: [Q] hw_ptr skipping: (pos=3588, delta=3588, period=512, jdelta=2/18/0, hw_ptr=0/0)
ALSA: PCM: [P] hw_ptr skipping: (pos=3820, delta=3820, period=512, jdelta=3/19/0, hw_ptr=0/0)
ALSA: PCM: [Q] hw_ptr skipping: (pos=2560, delta=2560, period=512, jdelta=1/13/0, hw_ptr=0/0)
ALSA: PCM: [P] hw_ptr skipping: (pos=2592, delta=2592, period=512, jdelta=2/13/0, hw_ptr=0/0)
ALSA: PCM: [P] hw_ptr skipping: (pos=2988, delta=2988, period=512, jdelta=4/15/1, hw_ptr=0/512)
ALSA: PCM: [Q] hw_ptr skipping: (pos=3436, delta=2924, period=512, jdelta=2/15/0, hw_ptr=512/512)
ALSA: PCM: [P] hw_ptr skipping: (pos=3900, delta=3388, period=512, jdelta=4/17/1, hw_ptr=512/1024)
ALSA: PCM: [P] hw_ptr skipping: (pos=276, delta=3348, period=512, jdelta=3/17/0, hw_ptr=1024/1024)
ALSA: PCM: [P] hw_ptr skipping: (pos=752, delta=3824, period=512, jdelta=5/19/1, hw_ptr=1024/1536)
ALSA: PCM: [P] hw_ptr skipping: (pos=1232, delta=3792, period=512, jdelta=3/19/0, hw_ptr=1536/1536)

"
Any idea why alsa/alsaloop would start skipping without any forewarning and have it not recover?

Update: The rapid restart thing seems to only work if it has already crashed once.

I am still running into this issue. Does anyone have any ideas or a forum that this might be better to talk about on?

Hi Jessie

You seem to have posted this question under DB410C rather than DB845C which probably won’t help (I’ll fix that in a second).

Additionally I think audio is known to be not working at present, at least according to last week’s release announcement:

1 Like

Funny enough I am using the DB410C. I switched branches to play with kernel 5 on my DB410C based off another post I found on here (I went looking for it and could not find it). It works as expected on the board with no issues to speak of other then this audio issue. Honestly, in a lot of ways it works better!

I know this is a very special case and probably a little strange but it has been giving me great results

All i’ve had to do to make all of it work is add an offset of 390 to my gpio (i.e. gpio16 would be gpio406) and one of the services(the one that had to do with LLMNR) didnt work right so I updated it and that fixed that.

I am going to go back to 4.14 to see if I am able to recreate this issue and updated the forum accordingly!

Thank you for your time!

This issue is “solved” with a post in a newer post.