periods*period_size vs. buffer_size; should they be equal?

[Stephen Warren <swarren@xxxxxxxxxx>]

I'm attempting to understand the layout of the DMA buffer used by ASoC
devices. It seems like the buffer should consist of runtime->periods entries
each of runtime->period_size frames of audio data. Hence, runtime->buffer_size
should be equal to runtime->periods * runtime->period_size in frames.

This assumption holds true in many cases. However, it doesn't in others:

(sizes in hex)

Playing WAVE '8000.wav' : Signed 16 bit Little Endian, Rate 8000 Hz, Stereo
[  217.910867] Trigger: runtime->periods=4
[  217.914696] Trigger: runtime->period_size=3e8
[  217.919043] Trigger: runtime->buffer_size=fa0
[  217.923389] Trigger: f2b(4)=10

Playing WAVE '11025.wav' : Signed 16 bit Little Endian, Rate 11025 Hz, Stereo
[  268.543821] Trigger: runtime->periods=5
[  268.547651] Trigger: runtime->period_size=400
[  268.551998] Trigger: runtime->buffer_size=1589

Playing WAVE '16000.wav' : Signed 16 bit Little Endian, Rate 16000 Hz, Stereo
[  315.889280] Trigger: runtime->periods=7
[  315.893109] Trigger: runtime->period_size=400
[  315.897456] Trigger: runtime->buffer_size=1f40

Yet for any higher sample rate the layout is identical:

Playing WAVE '96000.wav' : Signed 16 bit Little Endian, Rate 96000 Hz, Stereo
[  385.494764] Trigger: runtime->periods=8
[  385.498594] Trigger: runtime->period_size=400
[  385.502941] Trigger: runtime->buffer_size=2000

Is my assumption wrong? Is there some bug somewhere?

The reason I ask is because the DMA engine I'm writing for doesn't directly
handle circular buffers. Hence, I'm kicking off a separate DMA request for
each period's worth of data. Originally, the code was wrapping based on
runtime->buffer_size, but this didn't work correctly when buffer_size wasn't
a multiple of the period size.

Thanks for any pointers!

-- 
nvpublic

_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel