2011/9/20 Clemens Ladisch clemens@ladisch.de:
Raymond Yau wrote:
ALSA: pcm: add snd_pcm_hw_rule_noresample() ...
ymfpci and emu10k1 have SNDRV_PCM_RATE_CONTINUOUS and support 8000Hz to 48000Hz
after this patch and if application using snd_pcm_hw_params_set_rate_resample(,pcm , params ,0)
why the supported rate is only 48000Hz ?
Because these cards run at 48 kHz and resample anything else. That the resampler is implemented in hardware does not make a conceptual difference, and just means that the resampler has low quality.
but snd_pcm_hw_params_get_rate_min() is still 8000Hz
This should not happen. I'd guess the rules engine hasn't noticed that some parameters affected by the new rule need to change.
Please try the patch below. But there might be drivers where other parameters are affected by SND_PCM_HW_PARAMS_NORESAMPLE, so I guess all parameter bits need to be set.
This patch won't affect the accuracy of the playback position of the ymfpci
Why should it?
I think the correct way for ymfpci is to add a period_bytes constraint (just like emu10k1 and au88x0) in addition of a switch to fixed rate at 48000Hz to force the application to choose a period time which is close to the interval of timer interrupt
snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_PERIOD_BYTES, 1024);
are there any problem in snd_pcm_drain(), snd_pcm_rewind() and snd_pcm_forward() when the driver let the application select any period time when those hardware mixing sound card 's DSP have to mix audio streams?
since hwptr is inaccurate, snd_pcm_rewindable() may need to return zero if it can only rewind to period boundary