[alsa-devel] DMix period_size should always be half of buffer size?

[Prabhu Sivaraja]

Thanks for your help Jaroslav. I am attaching the debug files from
/proc/asound/card0/pcm0p/sub0 that I captured while playing a wav file
through aplay. I have attached both instances with 64KB bufsize/32KB
periodsize(works) and 64KB bufsize/4KB periodsize(does NOT work).

Here are the weird things I noticed in the attached debug captures. Maybe it
would make more sense to you.
1. If you take a look at the hw_params file you would see that period and
buffer size reported are 1/4th of what I have declared in the driver. Why is
this? Seems weird.

2. Status file clearly shows the hw_ptr has not moved in the 4KB period
size. I captured these files few secs after starting aplay. hw_ptr never
increments from 0 when period size size is NOT half the buf size. About
calling period_elapsed( ) like you mentioned in your mail, dont you think it
is irrelevant because the hw_ptr never moves to begin with? If it moved for
the first period and then never moved I could see how calling
period_elapsed( ) would matter but in this case where it never moved from
the beginning.

Regards
Prabhu.


On 5/4/07, Jaroslav Kysela <perex at suse.cz> wrote:
>
> On Thu, 3 May 2007, Prabhu Sivaraja wrote:
>
> > This is a followup to my earlier question about dmix not being able to
> mix
> > small files. I investigated it more and here is what I found.
> >
> > Again background info.
> > I have a 64KB as kernel buffer and a 64KB circular buffer for my device.
> In
> > a poll thread I copy the data obtained from ALSA lib from the kernel
> buffer
> > to my device circular buffer by keeping track of appl_ptr and
> hw_ptr(dmix
> > only). Everything was working fine except when I was trying to mix files
> > smaller than 64KB(my buffer size), the small file was not getting mixed
> > through the dmix plugin. Anything over 64KB was getting mixed just fine.
> So
> > I set about reducing my period size from 32KB to 4KB while maintaining
> my
> > buffer size at 64KB.
> >
> > When I tried to do this my hw_ptr never gets incremented from 0. Hence
> my
> > driver is stuck in a loop waiting for bytes to copy. This is only
> observed
> > when I am using dmix plugin and NOT when using hw or plughw. When my
> period
> > size is half the size of my buffer everything works fine with dmix (I
> > verified this by reducing my buffer size to 8KB and making my period
> size
> > 4KB. hw_ptr gets incremented then but I get buffer problems). It seems
> like
> > dmix is forcing me to keep my period size half the size of my buffer. hw
> and
> > plughw devices do not seem to do that.
> >
> > Is this a limitation of dmix. Could anyone comment on the dmix
> limitation
> > that I am experiencing.
>
> No, dmix works with more periods well. Send us debug info from
> /proc/asound/card0/pcm0p (when the stream is opened) and check, if your
> driver notifies higher PCM level with period_elapsed() and if your
> position callback returns right value when the stream is started.
>
>                                                Jaroslav
>
> -----
> Jaroslav Kysela <perex at suse.cz>
> Linux Kernel Sound Maintainer
> ALSA Project, SUSE Labs
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 32KBPeriodSize.tar.bz2
Type: application/x-bzip2
Size: 617 bytes
Desc: not available
Url : http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20070504/36b913ed/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4KBPeriodSize.tar.bz2
Type: application/x-bzip2
Size: 600 bytes
Desc: not available
Url : http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20070504/36b913ed/attachment-0001.bin