|
I2S is a serial format multiplexing left and right channels on a word basis, not a bit basis. Two pairs of 24-bits, in your example. A multiple of 3 or 6 bytes will not fit into any generally usable binary multiple, including sector (512 byte) or cluster boundaries in files/media.
In terms of DMA, I'll assume you don't have split sources for left/right channels, I'll further assume that the DMA/memory bandwidth is several orders of magnitude faster than the audio play rate. Provided your data matches the bit flow and endian-ness of the codec then sending data a byte at a time (in perhaps groups/multiples of 24 bytes (240, 480, 2400, 6144, 48000, 49152, ...), divisible by 3, 6 and 4) is the most workable and keep the channels in sync. Doing 16 or 32-bit DMA will always be more problematic due to endian issues, and channel separation. At some level you'll likely need to deal with transcoding the data from your source format, to the output format. If not for the format itself, then for the fact that the data doesn't fit cleanly into binary bins. For example taking groups of 24-bytes of input and creating 32-bytes of output with 32-bit alignment, or taking 24-bytes and simply modify it into 24-bytes ordered suitable for the shifter/DMA. If it is just a matter of bit/byte ordering to use 16/32-bit DMA transactions you could always store the data in that format by transcoding the file once and storing the result.
You could also handle playing direct from the file system, by playing the bulk of the data within a cluster, and handling a small inter-cluster splicing area on the fly, before proceeding with the rest of the next cluster. Personally, I just use a worker thread to pull in and transcode the data, and have the DMA interrupts ping/pong between two output buffer areas.
|
Forum
