I don't see any similar bug reports; Dylan, have you heard of anything like this recently?

> Restarting cras immediately fixes this.

This worked the first time. The second time I had to sign out/back in after restarting cras before playback started working

I'm seeing something similar but restarting CrAS doesn't fix it. For Kahlee at least, issuing a cras_test_client --plug 6:1:0 magically makes playback start working. I haven't had time to debug on other platforms yet to see if it's similar there.

This might be a regression.
Note that in #0 "Restarting cras immediately fixes this.". Autotest can not catch this because it restarts cras in the beginning of the test.
But for issue like #3, autotest should catch it.

Kalin, could you please check whether this is issue on some platform only, or across different platforms ?

Thanks!

What's the repro rate on bigdaddy? What's the version? If you can still repro, please submit a feedback report right after it fails on bigdaddy.

The error messages in #0 suggests that snd_ctl_pcm_info fails:

https://cs.corp.google.com/chromeos_public/src/third_party/adhd/cras/src/server/cras_alsa_card.c?type=cs&q=%22Could+not+get+info+for+device%22+package:%5Echromeos_public$&l=374

Restarting CRAS fix the issue just might be the fact that snd_ctl_pcm_info works after long time enough after boot.

snd_ctl_pcm_info is the same call "aplay -l" use to list device.
http://git.alsa-project.org/?p=alsa-utils.git;a=blob;f=aplay/aplay.c;h=e58e1bcbdd7e5c784b85df90f15ef41326d3f6dd;hb=HEAD#l295

so, you might be able to repro the issue with aplay -l early at boot.

And after that you'll need to check why kernel fails to reply snd_ctl_pcm_info, that is, 

ioctl(hw->fd, SNDRV_CTL_IOCTL_PCM_INFO, info) 

https://chromium.googlesource.com/chromiumos/third_party/alsa-lib/+/e1c876a2f0df6c658a5ea0ddde14ee7201fd124b/src/control/control_hw.c#268

I haven't been able to repro again on Bigdaddy so this might be an issue specific to Kahlee. I'll open an internal bug for that.