alsa-project/alsa-lib issue #320 was edited from ossilator:
this setup: ``` Plug PCM: Rate conversion PCM (44100, sformat=S16_LE) Converter: libspeex (external) Protocol version: 10003 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 17832 period_size : 4458 period_time : 92879 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 4458 period_event : 0 start_threshold : 17832 stop_threshold : 17832 silence_threshold: 0 silence_size : 0 boundary : 5019261784704417792 Slave: Hardware PCM card 0 'E-MU 0404b PCI [MAEM8852]' device 3 subdevice 0 Its setup is: stream : PLAYBACK access : MMAP_NONINTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 16384 period_size : 4096 period_time : 92879 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 4096 period_event : 0 start_threshold : 16384 stop_threshold : 16384 silence_threshold: 0 silence_size : 0 boundary : 4611686018427387904 appl_ptr : 0 hw_ptr : 0 ``` garbles the output rather impressively, though it's still recognizable as the input, more or less.
it happens both when up-sampling and down-sampling. it doesn't happen when not re-sampling.
it doesn't happen when the hardware takes 32-bit samples, so i guess it's somewhere in the optimized s16 paths.
it doesn't happen with mono.
this is not reproducible with the upstream emu10k1 driver, as the multichannel device demands 16 channels, which causes the route conversion plugin to be inserted, which sidesteps the issue. and the regular pcm device accepts any rate.
Issue URL : https://github.com/alsa-project/alsa-lib/issues/320 Repository URL: https://github.com/alsa-project/alsa-lib