I have a problem with the kernel driver snd_intel_sst that does not always start.
Here is a sample of the journal entries :
[ 12.477269] _dhd_wlfc_mac_entry_update():1644, entry(32)
[ 113.800541] snd_intel_sst: runtime_resume called
[ 113.821053] snd_intel_sst: FW Version 01.09.00.02
[ 113.821076] snd_intel_sst: Build date Jan 14 2014 Time 20:08:46
[ 113.821390] snd_intel_sst: Alloc for str 1 pipe 0x90
[ 113.827493] snd_intel_sst: Start for str 1 pipe 0x90
[ 114.541757] snd_intel_sst: Stop for str 1 pipe 0x90
[ 114.542623] snd_intel_sst: Free for str 1 pipe 0x90
[ 114.546513] snd_intel_sst: runtime_idle called
There is almost 100 seconds before the audio is available at boot. This happens randomly, since sometimes the driver starts normally. I have the same behavior on all Edison modules that I have used in our products. This is causing us some headaches since our product (an audio communication device) needs to have the audio working at startup. This delay is making our device unusable.
Somebody have experienced this problem ? Can this be solved ?
Thanks for your help!
How are you checking the delay? Are you just calculating it or can do you have a log for that? Did you make any changes to set ALSA? Have you tried unbinding and binding the module on boot?
Have look at the timestamps in the log entries (journald) in my first post. Before snd_intel_sst starts, there is a time grap from (12.47 sec to 113.80 sec). When everything works fine, there is no delay in the initialization of snd_intel_sst. I am using the standard Edison image and I have not made changes to the kernel. In fact the this is not a loadable module, but it is rather compiled with the kernel. We use the "dummy" driver with an external codec.
Using the latest image I was able to note a delay of up to 10 seconds but nothing around the time you report, look at the logs:
[ 1.963615] snd_intel_sst: INFO: ******** SST DRIVER loading.. Ver: 3.0.8
[ 1.964166] snd_intel_sst: Got drv data max stream 25
[ 1.966891] snd_intel_sst: intel_sst_probe successfully done!
[ 1.966956] snd_intel_sst: runtime_idle called
[ 1.966976] snd_intel_sst: runtime_suspend called
[ 10.515329] snd_intel_sst: runtime_resume called
[ 10.563826] snd_intel_sst: FW Version 01.09.00.02
[ 10.563853] snd_intel_sst: Build date Jan 14 2014 Time 20:08:46
[ 10.563965] snd_intel_sst: Alloc for str 14 pipe 0xe
[ 10.745272] snd_intel_sst: Free for str 14 pipe 0xe
[ 10.746856] snd_intel_sst: runtime_idle called
This is the usual behavior my Edison has, could you let us know if there is any other detail we have to replicate in order to see this delay, like the image you are using, which expansion board you're using, how are you powering the board and any processes/programs we should be aware of.
I have made some tests on the http://www.intel.com/buy/us/en/product/emergingtechnologies/intel-edison-breakout-board-kit-432539 Intel for Intel® Edison Breakout Board Kit and the problem does not occur by just booting the kernel. It seems the problem occurs when there is actual hardware connected to the I2S port. We are still figuring out what is causing this. We are using a custom design for the PCB which also includes multiple sensors connected to the I2C (gyro, accelerometer, IR proximity), lithium battery charger IC, and the codec. Unfortunately, that would not be possible for you to test this setup and we cannot share the complete design. However, it would be interesting to test if you have delays with this kit : http://www.malinov.com/Home/sergeys-projects/audio-block-for-intel-edison Audio Block for Intel Edison - Malinov Family Web Presence . Do you have access to this hardware ?
I will keep you informed of our progress.