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
