Why size of DMA transfer is 5 times number of samples?

[parrado]

I know this isn't an issue, but I'm wondering why DMA transfer size is 5 times number of samples instead of 4 times.

In addition I'd like to know how audio samples are stored in memory in order to apply some audio effects.

Thanks in advance.

[artvvb]

Interesting question. Digilent doesn't have a user manual for the I2S IP, so the answers aren't immediately available.

Looks like NR_OF_SMPL_I here is directly controlled by u32nrSamples here.

The DMA controller can accept fewer samples than the count specified in the SimpleTransfer call, and terminate a transfer "early" without error when it sees a tlast beat in the AXI stream. So, I suspect that the actual amount of memory written to is less than specified, and would be 4x sample count as expected. As long as the memory above the captured samples is zeros, this also ought to not be noticeable in playback, just some extra nothing after the actual recording is played.

I'm not positive, but there might be an off-by-one error in the logic generating the i2s_stream module's S2MM tlast or tvalid signal, causing a protocol violation that is getting masked by the inclusion of the x5 instead of x4 transfer size. If x4 was used, the DMA would might either throw an error due to not seeing a tlast stream beat, or it might drop the last sample. Depends on how the AXI DMA is implemented, I'm not positive what the behavior of the core is when a tlast signal appears without a corresponding tvalid & ready - it shouldn't be counting it as a last beat by protocol spec, but not sure.

I don't see any data packing, so the layout should just be one sample per 32-bit word, padded with zeros above the bottom N bits, with bit count depending on the IP configuration.

I haven't checked any of this in hardware or done much simulation though, will debug further when I get a chance.

Also, this particular repo isn't getting further updates. The sources have been moved over to the dma-audio branches of the Zybo-Z7 repo. Documentation for the moved demo can be found here. The possible bug could have been fixed since, but I expect it probably hasn't.

Thanks, Arthur

[parrado]

Interesting question. Digilent doesn't have a user manual for the I2S IP, so the answers aren't immediately available.

Looks like NR_OF_SMPL_I here is directly controlled by u32nrSamples here.

The DMA controller can accept fewer samples than the count specified in the SimpleTransfer call, and terminate a transfer "early" without error when it sees a tlast beat in the AXI stream. So, I suspect that the actual amount of memory written to is less than specified, and would be 4x sample count as expected. As long as the memory above the captured samples is zeros, this also ought to not be noticeable in playback, just some extra nothing after the actual recording is played.

I'm not positive, but there might be an off-by-one error in the logic generating the i2s_stream module's S2MM tlast or tvalid signal, causing a protocol violation that is getting masked by the inclusion of the x5 instead of x4 transfer size. If x4 was used, the DMA would might either throw an error due to not seeing a tlast stream beat, or it might drop the last sample. Depends on how the AXI DMA is implemented, I'm not positive what the behavior of the core is when a tlast signal appears without a corresponding tvalid & ready - it shouldn't be counting it as a last beat by protocol spec, but not sure.

I don't see any data packing, so the layout should just be one sample per 32-bit word, padded with zeros above the bottom N bits, with bit count depending on the IP configuration.

I haven't checked any of this in hardware or done much simulation though, will debug further when I get a chance.

Also, this particular repo isn't getting further updates. The sources have been moved over to the dma-audio branches of the Zybo-Z7 repo. Documentation for the moved demo can be found here. The possible bug could have been fixed since, but I expect it probably hasn't.

Thanks, Arthur

Thank you for such elaborated answer. I had same suspect as you regarding a bug in I2S stream generation, but 5 x Nsamples bytes leads to Nsamples extra bytes, which I consider it's a lot.

Anyway, I'm closing the issue as I've managed to implement some digital audio effects after sign extending the 24-bit samples. I'll make an in depth analysis of RTL and possibly some simulations.

Thanks again.