At Fri, 30 Apr 2010 08:44:24 -0500, pl bossart wrote: > > >> 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.
The biggest problem I can foresee is the handling of PCM position. In the current implementation, the PCM position continues to go over the buffer size until the certain boundary that is close to long int max. Without interrupts (i.e. snd_pcm_period_elapsed()), this position update won't work reliably. If we reduce boundary size as buffer size, certainly some code in alsa-lib (or kernel PCM) would be confused. Thus, before disabling the interrupts completely, we need to revisit the PCM position handling all over places. But in general, I think it's fine to implement such a mode -- it's more intuitive than the current free-wheel mode we have now. BTW, I'm still wondering whether disabling the IRQ would really give so much gain compared with periods=1 or 2 case. I thought all this was about the power-saving, no? Did someone measure a significant difference between periods=0 and periods=2 in this regard? thanks, Takashi _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss