On 03/28/2007 01:40 PM, Takashi Iwai wrote:
At Wed, 28 Mar 2007 13:03:51 +0200, Rene Herman wrote:
Bingo, that's it. "arecord --period-size=4096 --buffer-size=16384 -f cd" works fine. I guess it should be forcing power of 2 then?
Only --period-size=4096 is not enough. It then has a buffer-size of 22016 and the stutter is there.
--buffer-size=8192 --period-size=4000 is fine though. So, buffer-size...
You can try snd_pcm_hw_constraint_pow2() there.
Seems to work nicely! With the attached, a simple "arecord -f cd" works without problem (it then sets buffer_size 16384, period_size 4096) and seems to be settling on the nearest power of two if I pass something in for buffer_size manually.
But, IIRC, power-of-two constraint causes problems when you use buffer_time instead of buffer_size. Anyway, worth try once.
I don't seem to be experiencing problems there either;
command | buffer_size/period_size ------------------------------------------------------------ arecord -f cd --buffer-time 100000 | 4096/1103 arecord -f cd --buffer-time 150000 | 8192/1654 arecord -f cd --buffer-time 200000 | 16384/2205
These all work fine. With --period-time:
command | buffer_size/period_size ----------------------------------------------------------- arecord -f cd --period-time 20000 | 16384/882 arecord -f cd --period-time 35000 | 16384/1544 arecord -f cd --period-time 50000 | 16384/2205
All fine again. If I try upsetting the thing on purpose with large values, I get errors (from arecord, not in the sound).
As far as I'm concerned this seems good to go. Signed-off-by/Tested-by and all that.
Rene.
diff --git a/sound/pci/es1968.c b/sound/pci/es1968.c index dc84c18..8130a87 100644 --- a/sound/pci/es1968.c +++ b/sound/pci/es1968.c @@ -1617,6 +1617,8 @@ #if 0 snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_BUFFER_BYTES, 1024); #endif + snd_pcm_hw_constraint_pow2(runtime, 0, SNDRV_PCM_HW_PARAM_BUFFER_BYTES); + spin_lock_irq(&chip->substream_lock); list_add(&es->list, &chip->substream_list); spin_unlock_irq(&chip->substream_lock);