Hello all,
here's one problem that I stumbled on with the deprecated snd_pcm_sw_params_set_xfer_align() function. I'm not sure if anything needs to be done to this, but at least FYI for other app developers that might hit the same issue.
In short, ecasound-2.7.0 was just released, and as one of the last commits, I dropped the call to snd_pcm_sw_params_set_xfer_align() as it has been deprecated since early 2008 in ALSA. Previously Ecasound had always set the xfer_align to 1.
Anyways, right after the release I got an error report (from Pierre, cc'ed) about bad glitches in audio with the new release, and the problem now appears to be deprecation of set_xfer_align. To summarize:
- app relies on xfer_align=1, and has previously set it explicitly - in kernels before 2.6.25, the xfer_align is initialized to period_size in pcm_native.c and to 1 in pcm_oss.c; but in 2.6.25 the field was removed altogether: http://git.alsa-project.org/?p=alsa-kernel.git;a=commit;h=d948035a928400ae12... - similar change was done to alsa-lib 1.0.16: http://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=cf15e49d8460d9b56005d...
Now the problematic combination is: - new application (not anymore calling set_xfer_align()) - old alsa-lib and kernel (still initializing xfer_size) - application used with an ALSA PCM that is strict about what period-sizes can be used (e.g. in the specific case we found out, ALSA PCM wouldn't accept a power-of-two period size)
This is common enough that some workaround is needed in apps, an in Ecasound's case case, I'll add some ifdef-magic to 2.7.1 so that xfer_align is still set if compiled against an older alsa-lib. That should cover majority of the cases...