[alsa-devel] Playback formats; does aplay pad S16_LE, or does the hardware?
I can successfully play 32b@32KHz and 32b@16KHz to my I2S DAC.
I can also, with the same settings as 32b@16KHz, play 16b@32KHz, but I don't think this is the way ALSA wants its data....
I've learned that hw_params is responsible for describing only what the hardware is supposed to be capable of. Does this mean the hardware needs to find a way to pad 0's on lower quality data for any given rate?
For example, when I play 32b @32 KHz, everything works. If I play 16b@32KHz, I shouldn't change any output clocks, but will also present the data on a 32bit data bus as 16bits padded with 0? Or does it pack the data such that the hardware needs to determine that it's in 16b mode, and pad the data itself?
Thanks, Rob
Rob Nertney wrote:
I can successfully play 32b@32KHz and 32b@16KHz to my I2S DAC.
I can also, with the same settings as 32b@16KHz, play 16b@32KHz, but I don't think this is the way ALSA wants its data....
I've learned that hw_params is responsible for describing only what the hardware is supposed to be capable of.
The hw_params values describe the format of the samples in memory. (If alsa-lib does format conversion, the application and the driver see different hw_params values.)
What the hardware does with the samples after the DMA controller has read them from memory is of no concern to the ALSA framework.
Does this mean the hardware needs to find a way to pad 0's on lower quality data for any given rate?
If the hardware is capable of that, then the driver can support 16-bit samples. (I don't know of any I²S controller that cannot do that.)
For example, when I play 32b @32 KHz, everything works. If I play 16b@32KHz, I shouldn't change any output clocks, but will also present the data on a 32bit data bus as 16bits padded with 0?
Which bus? The memory bus, or the I²S bus?
Regards, Clemens
participants (2)
-
Clemens Ladisch
-
Rob Nertney