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
