On Thu, Dec 4, 2014 at 5:20 PM, Clemens Ladisch clemens@ladisch.de wrote:
Carlo Caione wrote:
Several user-space programs (like aplay) work well with my hw, since the buffer sent from the user-space is always (padded) of period-size bytes, that is aligned to my 64 bytes boundary. Others (like speaker-test) are not working because sometimes they snd_pcm_writei() a buffer that is not multiple of 64 bytes.
When a program writes two chunks of 32 bytes each, the final contents of the memory are the same. So what exactly is the problem?
Hi Clemens, let's say that our application sends uning snd_pcm_writei() a buffer that is exactly 64 bytes and that our hwoff (appl_ofs) is pointing to a memory location 0 in the DMA area. When this buffer is taken from the SoC sound driver, the .copy callback writes this buffer as follow: 32 bytes (left channel) to memory locations from *hwoff to *hwoff+31, and 32 bytes (right channel) for *hwoff+32 to *hwoff+63. Problem is when my buffer is not multiple of 64 bytes, for example if the buffer size is < 64. If I receive a buffer of lenght 32 byte than my DMA memory is filled as follows: 16 bytes from *hwoff to *hwoff+15 and 16 bytes from *hwoff+32 to *hwoff+47, leaving 32 bytes in the block not initialized. My hardware is always expecting to read a block of data (64 byte) for *hwoff to *hwoff+63 and it actually does, reading rubbish from the memory locations not initialized. Even worst my hw requires that the hw pointer is always aligned to 64 bytes and now my new hw pointer is at *hwoff+32 that is not aligned on the boundary. In some way I should always guarantee that the size of the buffer passed to my .copy callback is multiple of 64 bytes.
I hope this clarifies a bit,