Dma use audio stream API #3162
Dma use audio stream API #3162
Conversation
|
Rerun CI to inlcude recent FW fix. |
|
SOFCI TEST |
src/lib/dma.c
Outdated
There was a problem hiding this comment.
Replacing specific dma buffer handling in host/dai components with consistent use of audio-stream api is a good idea since the dma buffer might be handled as an audio-stream by other parts as well (like pcm-converter code).
Regarding this specific line, when called by dai component, the dd->frame_fmt used previously is replaced with source->stream.frame_fmt now, so assert(==) before a call might be a good idea to make sure they are consistently updated. Another option is to remove dd->frame_fmt completely and pass the setting to the audio-stream if possible (audio-stream already attached when dd->frame_fmt is configured?)
There was a problem hiding this comment.
can we make sure there are no dependencies on PCM formats in DMA buffers? we will use DMAs for compressed formats.
There was a problem hiding this comment.
can we make sure there are no dependencies on PCM formats in DMA buffers? we will use DMAs for compressed formats.
I'm not familiar with compressed audio streams, but I guess it should be next data format, like SOF_IPC_FRAME_MP3_LE, isn't it? If so, then conversion should be done in pcm_converter, in flow like host.dma_buffer->(mp3) pcm_converter-> (arbitrary pcm) host.local_buffer or are you going to do separate component and create flow like host.dma_buffer->(mp3) pcm_converter-> (mp3) host.local_buffer -> (mp3) decompresser -> (pcm, eg s32) pcm_converter -> (arbitrary pcm) ?
There was a problem hiding this comment.
I don't think converters will really work on compressed formats. I think in the compress situation the pipeline must be something like host.dma_buffer->(mp3) decompresser ->(pcm, say s24le) pcm_converter ->(pcm, whichever is demanded by further components)
There was a problem hiding this comment.
Then passing number of bytes from source buffer in dma_buffer_copy_*() probably will be better idea - more universal solution.
ktrzcinx
force-pushed
the
dma-use-audio-stream
branch
2 times, most recently
from
5ddcc29 to
6fe778c
Compare
|
SOFCI TEST |
|
depends on #3174 |
ktrzcinx
force-pushed
the
dma-use-audio-stream
branch
2 times, most recently
from
ceca95b to
2dc2c9f
Compare
|
@mmaka1 @plbossart comments resolved ? |
plbossart
left a comment
plbossart
left a comment
There was a problem hiding this comment.
I am still not clear on the ties between buffers and samples, see below
src/lib/dma.c
Outdated
There was a problem hiding this comment.
I was good with this patch since it used bytes instead of samples, which is a good thing to do when dealing with DMAs, but this re-introduces samples which may not be correct in all cases if the data is not PCM.
There was a problem hiding this comment.
I will remove this samples number calculation from this place, but I need changes from this one and one more PR , let me do it step-by-step. Even this PR needs changes from #3174, I wouldn't like to make too long PR dependency chain
There was a problem hiding this comment.
ok, looks like we are in agreement on directions, fine with me if we do this in steps, as long as each PR doesn't break because the others are missing.
|
Travis CI reports errors? |
ktrzcinx
force-pushed
the
dma-use-audio-stream
branch
from
2dc2c9f to
3320ae6
Compare
|
@ktrzcinx some CI issues and conflicts. |
|
@lgirdwood I'm waiting for #3174, because CI will claim in this PR without it. |
ok, can you reply to @plbossart comments to move it forward. |
Each audio_stream should have set valid metadata information. Signed-off-by: Karol Trzcinski <karolx.trzcinski@linux.intel.com>
ktrzcinx
force-pushed
the
dma-use-audio-stream
branch
from
3320ae6 to
555e2dd
Compare
|
SOFCI TEST |
This value is strictly correlated with given samples number, passing sink/source bytes number as separate parameter may lead to data desynchronization. Temporary number of samples and sink_bytes is calculated in dma_buffer_copy_*() function, but it should be removed in future. 'process' should be modified to take only number of bytes to process from source stream and return number of output bytes in sink stream, to allow easily handling of compressed audio streams. Signed-off-by: Karol Trzcinski <karolx.trzcinski@linux.intel.com>
Usage of function from audio_stream component updates avail/free fields. Moreover using generic function helps in maintaining code. Signed-off-by: Karol Trzcinski <karolx.trzcinski@linux.intel.com>
ktrzcinx
force-pushed
the
dma-use-audio-stream
branch
from
555e2dd to
aff001d
Compare
|
@plbossart I accidentally clicked re-review while the browser was refreshing the list processing previous click on my name. Pls ignore. |
5 participants
Small DMA fixes extracted from #3156
depends on #3174