solved. it turned out that "trusting" the driver was key: >> if (snd_pcm_avail_update(pcm) < period_size) >> break; >> count = period_size;
this was the key point. sometimes when we returned from poll(2), snd_pcm_avail_update() would indicate period_size+1 frames available. needless to say, using the value causes things to get wacky pretty quickly. the code above is not quite right, but its close. count = (avail / period_size) * period_size; since its possible to have been delayed in scheduling and there may in fact be N periods waiting. this is more efficient than going back into poll after handling 1 period. thanks very much for pointing me in the right direction. this is great. for those not on jack-devel, we now have an N-channel capture client (it records from any set of JACK ports) plus alsaplayer working via JACK now. --p _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel