Paul Davis wrote:
>
> 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;
count = avail - avail % period_size;
is more efficient (at least on i386 and gcc).
>
> 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.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project http://www.alsa-project.org
It sounds good!
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
