[alsa-devel] dmix does not mix small files??
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.
Background info. ----------------------- In my ALSA driver I have thread that keeps track of hw_ptr(dmix) appl_ptr(for all other cases) and copies the incoming data from kernal buffer into device circular buffer(which is monitored by the device). I allocate 64KB kernal buffer in my module_init function . (See allocation below) snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_CONTINUOUS, snd_dma_continuous_data(GFP_KERNEL), 64*1024 , 64*1024);
So I monitor this kernal buffer and copy data from this to my device circular buffer which is also 64KB.
My period size is defined as 32KB. (See below) substream->runtime->hw.period_bytes_min = 1024*32; substream->runtime->hw.period_bytes_max = 1024*32; substream->runtime->hw.periods_min = 2; substream->runtime->hw.periods_max = 2;
My asound.conf file pcm.mix { type dmix ipc_key 1024 slave { pcm "hw:0,0" rate 48000 } } pcm.!default { type plug slave.pcm "mix" }
Everything was working fine until I noticed something weird. When I am playing a long wav file by invoking aplay and then try and play another small wav file simultaneously, the second file never gets mixed if the file is less than 64KB(my buffer size). If the second file is larger than 64KB then the second file gets mixed with the first one as it should since I am using dmix plugin.
So in order to debug this I tried to decrease my period_size = 4KB but when I do this my hw_ptr never moves.
My question. 1. Why do you think a file smaller than 64KB does not get mixed. (Obviously it has something to do with my buffer size but I dont get why?) 2. When I decrease my period_size to 4KB while keeping my buffer size at 64KB, why doesnt my hw_ptr move? 3. How else would I debug this?
Thanks in advance. I would really appreciate any help.
Regards Prabhu.
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 - 1) / 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
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
participants (2)
-
Jaroslav Kysela -
Prabhu Sivaraja