Your analysis is not quite correct; ALSA should absolutely not be
playing more samples than it receives regardless of period/hardware
buffer alignment. The only way this could happen is if the pipeline
is set to 'never underrun' mode and the playback cursor passes the
end of playback before a stop can be issued. Note that this mode is
deprecated and doesn't exist in modern ALSA and libao never used this
mode anyway.
In the code you point to, the silent padding was being used for two
things, but both were because aplay/sox/etc were using ALSA in a mode
where transfers were being force-aligned to a chunk size, and the
transfer would not trigger until the chunk was full. This mode is
also deprecated in ALSA and no longer exists. All transfers are now
aligned on single samples ('frames'). In short, all this extra
silence padding code has done nothing in many many years. It exists
only because developers have been too lazy to remove it (several of
these interfaces were deprecated before anyone had even written
complete documentation for them!) I'm betting that some drivers were
never properly updated, or have always been buggy with respect to
transfer alignment.
That said, both your example sox command line (with ao) and your bug
illustration program work properly here; I am not able to reproduce
your problem on any hardware I have (or on other distros, eg, Ubuntu,
Fedora or RHEL). This also suggests a specific buggy ALSA driver or
libasound version which may have been fixed since.
Is this consistently a problem on other machines / after updates?
What hardware, driver versions and kernel are you using specifically?
I'm sure this is an ALSA problem, not a libao problem.
Monty
Xiph.Org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
