[alsa-devel] dmix and sounds less than 64kb

[Takashi Iwai]

At Thu, 19 Jul 2007 12:59:32 -0700,
Aaron "Caustik" Robinson wrote:
> 
> We have found that the problem exists because, at certain points in time,
> the hardware pointer and application pointer overlap. Basically the hardware
> is reading from the period buffer which is currently being written to. How
> might this be platform specific? Is there any debugging technique you think
> may help find the root cause?

It sounds unlikely a platform-specific problem but rather a problem of
the driver implementation.

Note that the hw_ptr and appl_ptr tracked in pcm struct are within 0
and (runtime->boundary_size - 1).  It's not within 0 and
(buffer_size-1).  So, basically it shouldn't overlap unless it goes
across the boundary close to long (32bit or more).


Takashi

> 
> On 7/10/07, Jaroslav Kysela <perex at suse.cz> wrote:
> >
> > On Tue, 10 Jul 2007, Aaron "Caustik" Robinson wrote:
> >
> > > This is on an embedded ARM device, with a custom driver. That's
> > > interesting. I never thought about the cache angle. Is there any sort of
> > > hack I can put to check if that is the problem?
> >
> > The cache flush method is quite CPU specific, you have to check datasheet.
> > But it's only guess and the problem might be somewhere else. I would
> > compare samples DMA ring buffer in the user space and kernel space again.
> > Also, put a debug lines to dmix plugin to detect where are samples written
> > (to which pointer/area in the DMA ring buffer). dmix assumes that playback
> > is running forever and tries to mix data in actual ring buffer position.
> >
> >                                                 Jaroslav
> >
> > -----
> > Jaroslav Kysela <perex at suse.cz>
> > Linux Kernel Sound Maintainer
> > ALSA Project, SUSE Labs
> >
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>