[alsa-devel] [RFC] disabling ALSA period interrupts

[Raymond Yau]

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.
> Cheers
> -Pierre
>

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]
  Subdevices: 3/3
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2