Thanks for your suggestion. I do agree with you. But when I change my period_size to 4KB and set number of periods to 16, my hw_ptr or appl_ptr never move from their initial value of 0. So you think this a driver problem? But the hw_ptr is not something the driver controls? Would appreciate if you could explain more on this.
Thanks. Prabhu.
On 5/3/07, Jaroslav Kysela perex@suse.cz wrote:
On Thu, 3 May 2007, Prabhu Sivaraja wrote:
Hi,
I've been stuck on this dmix problem for the past week and have tried everything under the sun. Please any help or comment is much
appreciated.
Thanks a lot.
For nice dmix support, it's better to have more periods than 2 and small ones. Your allowed configuration 2 x 32KB is not very good.
But judging from the current dmix code, this code may cause to skip large count of samples or your driver behaves badly:
/* If we have too litte periods, better to align the start position
- to the period boundary so that the interrupt can be handled properly
- at the right time.
*/ dmix->slave_appl_ptr = ((dmix->slave_appl_ptr + dmix->slave_period_size -
/ dmix->slave_period_size) *dmix->slave_period_size;
It's from changeset:
hangeset: 2109:349c0b0018b9 user: tiwai date: Fri Mar 24 14:53:41 2006 +0000 files: src/pcm/pcm_direct.c src/pcm/pcm_dmix.c description: Fix noisy output of dmix with two periods
Fixed the noisy output of dmix with two (or less) periods. The dmix tends to give noise or XRUN when running with two periods because of its implementation nature. To avoid this, the start position is aligned to the period size, so that the updates are synced with interrupts of slave PCM.
So in order to debug this I tried to decrease my period_size = 4KB but
when
I do this my hw_ptr never moves.
Driver problem?
Jaroslav
Jaroslav Kysela perex@suse.cz Linux Kernel Sound Maintainer ALSA Project, SUSE Labs