Re: [alsa-devel] [pulseaudio-discuss] [PATCH] alsa: Disable timer-scheduling for PCMs with the BATCH flag
PCM Devices which have the BATCH flag set update the PCM pointeronly with
period size granularity. Using timer based scheduling does not haveany
advantage in this mode. For one devices which have that flag setusually
update the position pointer in software after getting the period interrupt.So
disabling the period interrupt is not possible for this kind ofdevices.
Furthermore writing to or reading from the buffer slice for thecurrent
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 kindof
hardware, which results in garbled audio output. This typically means that timer based scheduling needs to be manually disabled on systems with suchdevices.
Auto disabling tsched in this case allows these systems to run withthe
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 ?
usb-audio seem update when each URB send/receive (in 1ms intervals)
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
the rewind_safeguard is affected by the size of FIFO buffer as you cannot rewind any data in FIFO buffer of DSP/ sound controller
At Tue, 3 Dec 2013 08:47:07 +0800, Raymond Yau wrote:
PCM Devices which have the BATCH flag set update the PCM pointeronly with
period size granularity. Using timer based scheduling does not haveany
advantage in this mode. For one devices which have that flag setusually
update the position pointer in software after getting the period interrupt.So
disabling the period interrupt is not possible for this kind ofdevices.
Furthermore writing to or reading from the buffer slice for thecurrent
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 kindof
hardware, which results in garbled audio output. This typically means that timer based scheduling needs to be manually disabled on systems with suchdevices.
Auto disabling tsched in this case allows these systems to run withthe
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
Takashi Iwai wrote:
Raymond Yau wrote:
usb-audio seem update when each URB send/receive (in 1ms intervals)
The default is to use larger intervals.
The usb-audio driver behaved in a BATCH way in the very early version, but it was improved.
The delay reporting is more precise, but the DMA position still jumps for each URB.
So we can get rid of the flag from this driver now.
How well does timer-scheduling work with large URBs?
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
The period length (in frames) is not constant for most sample rates.
However, if the noresample flag is set (which should be the case with PA), the period length should be constant, and such a period constraint might make sense. I'll have to test it ...
Regards, Clemens
At Tue, 03 Dec 2013 10:02:44 +0100, Clemens Ladisch wrote:
Takashi Iwai wrote:
Raymond Yau wrote:
usb-audio seem update when each URB send/receive (in 1ms intervals)
The default is to use larger intervals.
The usb-audio driver behaved in a BATCH way in the very early version, but it was improved.
The delay reporting is more precise, but the DMA position still jumps for each URB.
So we can get rid of the flag from this driver now.
How well does timer-scheduling work with large URBs?
I thought PCM runtime delay should give the accurate sample position, irrespective to URB size? It should suffice for PA to control via timer scheduling.
Takashi
Takashi Iwai wrote:
Clemens Ladisch wrote:
Takashi Iwai wrote:
Raymond Yau wrote:
usb-audio seem update when each URB send/receive (in 1ms intervals)
The default is to use larger intervals.
The usb-audio driver behaved in a BATCH way in the very early version, but it was improved.
The delay reporting is more precise, but the DMA position still jumps for each URB.
So we can get rid of the flag from this driver now.
How well does timer-scheduling work with large URBs?
I thought PCM runtime delay should give the accurate sample position, irrespective to URB size?
The position of the sample that is currently being played is accurate (rounded to a USB frame). The DMA position, however, changes only in URB-sized increments. (And that is accurate too, because it describes exactly how the data is copied out of the buffer.)
It should suffice for PA to control via timer scheduling.
Large jumps in the DMA position mean that there is a large part of the buffer which cannot be safely changed by PA. If this is why PA wants to disable tsched, then the BATCH flag should stay.
Regards, Clemens
participants (3)
-
Clemens Ladisch -
Raymond Yau -
Takashi Iwai