The lx6464es driver advertises both 16-bit and packed 24-bit PCM formats,
but lx_trigger_start() and lx_interrupt_request_new_buffer() calculate the
DMA period size as runtime->period_size * runtime->channels * 3. That is
only correct for the packed 24-bit formats.
For 16-bit streams the driver submits buffers that are 50% larger than the
actual ALSA period and advances the DMA address by the same wrong amount.
For example, with 2 channels, 256 frames and 4 periods, the third buffer
already extends beyond the ALSA buffer and the fourth buffer starts outside
it.
Use snd_pcm_lib_period_bytes() so the byte count matches the runtime
format, channel count and period size.
Fixes: 02bec4904508 ("ALSA: lx6464es - driver for the digigram lx6464es interface")
Cc: stable@vger.kernel.org
Signed-off-by: Xu Rao <raoxu@uniontech.com>
Link: https://patch.msgid.link/8BB12E8D92A7CDBA+20260723085710.2567463-1-raoxu@uniontech.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
int err;
- const u32 channels = substream->runtime->channels;
- const u32 bytes_per_frame = channels * 3;
- const u32 period_size = substream->runtime->period_size;
const u32 periods = substream->runtime->periods;
- const u32 period_bytes = period_size * bytes_per_frame;
+ const u32 period_bytes = snd_pcm_lib_period_bytes(substream);
dma_addr_t buf = substream->dma_buffer.addr;
int i;
const unsigned int is_capture = lx_stream->is_capture;
int err;
- const u32 channels = substream->runtime->channels;
- const u32 bytes_per_frame = channels * 3;
- const u32 period_size = substream->runtime->period_size;
- const u32 period_bytes = period_size * bytes_per_frame;
+ const u32 period_bytes = snd_pcm_lib_period_bytes(substream);
const u32 pos = lx_stream->frame_pos;
const u32 next_pos = ((pos+1) == substream->runtime->periods) ?
0 : pos + 1;