Repository navigation
SRC: Add support for timer based scheduling - #1219
Conversation
|
Note: There is still problem that often but not always with 44.1 -> 48 kHz playback just when the playback ends the firmware crashes. It does not happen with 8/16/32/48 -> 48 KHz. Also build with xt-xcc does not have this issue (both identical source code to gcc and the intrinsic optimized version). I haven't found out why. Anyway, I made this PR available because currently SRC pipes do not work at all. |
|
This fixes SOF issue #1147. |
|
@singalsu have you used the crash-dump script to investigate the crash. Is it a consistent crash between builds/boots ? |
lgirdwood
left a comment
lgirdwood
left a comment
There was a problem hiding this comment.
Cant' see any obvious changes that would kill stream stop, but it maybe that certain combinations are corrupting heap/stack.
There was a problem hiding this comment.
Better to wrap it up into some function.
|
@lgirdwood I haven't been able to decode manually anything useful from this crash dump I noticed today that the error trace gets updates just at time time of playback stop and crash. The normal DMA trace doesn't contain this. Here's the trace: Though no errors those I could spot seen there. Maybe the 44.1 kHz playback (and gcc build) does something that causes the idle to crash. |
|
I'll see also if testbench can catch something. |
This patch adds to SRC for timer based scheduling capability to determine in copy() the number of frames to process. Due to potentially high computational load the max amount to process is limited to just exceed the nominal number of frames per scheduling rate. It prevents SRC to be preempted due to too long processing time and cause pipeline xruns in the start of playback when the buffers contain a large number of frames. The pre-fill of samples in first copy() is removed since the just above period length of data processing target avoids the sink buffer to get too small number of frames for the downstream pipeline. The currently happening bad metallic sound with SRC in pipeline is fixed by this patch. Signed-off-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>
061e376 to
1499795
Compare
|
@tlauda I just pushed fixes for the issues you found. The fail probability possibly decreased with this change but still exists. I'll continue testing in testbench this with valgrind etc. |
|
@singalsu some updates have been merged to crash dump very recently, can you try todays HEAD. I would expect to see registers but they all appear zero. |
|
Hmm, if I change SRC code to free the filter delay lines in reset() the 44.1 kHz crash does not happen... I'm confused why this changes things since xt-xcc code build was fine. It could be still some memory corruption somewhere. Tomorrow valgrind... |
|
@singalsu Try to force push the branch - it will reschedule the CI. |
|
@lgirdwood @tlauda I'm now able thanks to PR by @jajanusz run this is testbench. It doesn't crash so no obvious mistake found yet. However valgrind found two issues that I need to check. One is for allocation and one is condition test with uninitialized variable. |
|
The test bench issues found by valgrind were in file.c component. I'll make a separate PR. |
|
@singalsu @lgirdwood Network down for CI. |
This patch adds to SRC for timer based scheduling capability to
determine in copy() the number of frames to process. Due to
potentially high computational load the max amount to process is
limited to just exceed the nominal number of frames per
scheduling rate. It prevents SRC to be preempted due to too long
processing time and cause pipeline xruns in the start of playback
when the buffers contain a large number of frames.
The pre-fill of samples in first copy() is removed since the just
above period length of data processing target avoids the sink
buffer to get too small number of frames for the downstream
pipeline.
The currently happening bad metallic sound with SRC in pipeline
is fixed by this patch.
Signed-off-by: Seppo Ingalsuo seppo.ingalsuo@linux.intel.com