[alsa-devel] [RFC] disabling ALSA period interrupts
superquad.vortex2 at gmail.com
Thu May 6 03:24:05 CEST 2010
2010/4/30 pl bossart <bossart.nospam at gmail.com>
> Hi Clemens,
> >> When PulseAudio is used and all PCM is routed through PulseAudio
> >> (Fedora, Meego, etc), the notion of ALSA periods isn't very useful.
> >> So why not disable them entirely to reduce the number of wakeups? ...
> >> There are probably some cases where you don't want this type of
> >> behavior (broken hardware, legacy code with multiple-buffering,
> >> disabled timer in PulseAudio),
> > It's interesting that all ALSA applications except PA are "legacy". :)
> Ha. Nice slip. I didn't mean legacy was bad... It's perfectly ok to
> use multiple buffers and interrupts in a variety of apps.
> >> so I think it would make sense to request the disabling of interrupts
> >> when hw_params are set, since this is also the time when period sizes
> >> are set.
> > Yes. For compatibility with the existing ALSA API, this needs to be
> > a flag that is not enabled by default.
> Agreed. This shouldn't even be mandatory since this option might not
> be possible in all platforms.
> >> I am aware that some changes would be needed in pcm_lib.c, where all
> >> the error checks are done.
> > Plus all the API changes in the ALSA kernel framework, the ALSA kernel/
> > userspace interface, and the alsa-lib interface.
> I am not following this point. If you add a simple flag to an existing
> interface, why would we need to change the kernel/userspace inferface?
> This change should be possible in a backwards compatible manner as an
> additional option provided to the application developer.
Do your proposal allow one application use "leagcy" method and the other
application use PA since my HDA codec seem allow multi streamming capture ?
card 1: Intel [HDA Intel], device 0: AD198x Analog [AD198x Analog]
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
More information about the Alsa-devel