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

[Aaron "Caustik" Robinson]

I dumped appl_ptr and slave_appl_ptr being sent to mix_areas - and the
numbers flow around the ring buffer in a steady circle. Here are graphs of
the data:

http://www.caustik.com/alsa/scat-appl_ptr.gif
http://www.caustik.com/alsa/scat-slave_appl_ptr.gif

So it looks like those values are moving like they should. However, I do not
know where to print the hardware pointer value. Where is that variable?

Btw - I noticed that the kernel in core audio will manipulate some buffer
pointers based on when the buffer is almost drained - is that relevant?

caustik

On 7/24/07, Takashi Iwai <tiwai at suse.de> wrote:
>
> 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
> >
>