[pulseaudio-discuss] [alsa-devel] [PATCH] alsa: Disable timer-scheduling for PCMs with the BATCH flag

[Takashi Iwai]

At Tue, 3 Dec 2013 08:47:07 +0800,
Raymond Yau wrote:
> 
> > >
> > >     PCM Devices which have the BATCH flag set update the PCM pointer
> > only with
> > >     period size granularity. Using timer based scheduling does not have
> > any
> > >     advantage in this mode. For one devices which have that flag set
> > usually
> > >     update
> > >     the position pointer in software after getting the period interrupt.
> > So
> > >     disabling the period interrupt is not possible for this kind of
> > devices.
> > >     Furthermore writing to or reading from the buffer slice for the
> > current
> > >     period
> > >     is not possible since the position inside the buffer is not known. On
> > >     the other
> > >     hand the tsched algorithm seems to get easily confused for this kind
> > of
> > >     hardware, which results in garbled audio output. This typically means
> > >     that timer
> > >     based scheduling needs to be manually disabled on systems with such
> > devices.
> > >     Auto disabling tsched in this case allows these systems to run with
> > the
> > >     default
> > >     configuration.
> > >
> > >
> > > If the playback position is reported in steps instead of monotonic
> > increasing ?
> > >
> > > does this mean that you also need to increase rewind_safeguard to one
> > period
> > > or modifiy snd_pcm_rewindable ?
> >
> >
> > Yes that makes sense. The safeguard should probably be 1.5 periods or 1
> > period + fixed value, since it will always take some time from when the
> > hardware reaches the next period to when userspace is notified about this.
> >
> > I'm unfortunately not that familiar with pulseaudio. Maybe there is a
> > better
> > way to fix this problem then to disable tsched. If anybody wants to
> > recreate
> > the issue it can easily be emulated by applying the following patch to your
> > kernel:
> >
> >
> does all alsa drivers with SNDRV_PCM_INFO_PATCH update the playback/capture
> position in period interrupt ?

In general, yes.

> usb-audio seem update when each URB send/receive (in 1ms intervals)

The usb-audio driver behaved in a BATCH way in the very early version,
but it was improved.  So we can get rid of the flag from this driver
now.

> ymfpci driver also update hwptr in 5ms interval but no SNDRV_PCM_INFO_PATCH
> and no constraint in period time must be interval of 5 ms

It's a subtle driver bug.  Feel free to fix it if you have a test
hardware :)  Otherwise, better not to touch such an old code.


Takashi