Jaroslav Kysela wrote: > > On Sun, 9 Dec 2001, Abramo Bagnara wrote: > > > Jaroslav Kysela wrote: > > > > > > On Sun, 9 Dec 2001, Abramo Bagnara wrote: > > > > > > > Jaroslav Kysela wrote: > > > > > > > > > > On Sat, 8 Dec 2001, Tim Goetze wrote: > > > > > > > > > > > the doc to snd_pcm_mmap_commit says > > > > > > > > > > > > * \return 0 on success otherwise a negative error code > > > > > > > > > > > > but on success it rather seems to return >= 0 (the number of frames > > > > > > commited i think). > > > > > > > > > > > > please clarify and fix. > > > > > > > > > > Yes, it's definitely wrong. The return value should be zero or an error. > > > > > The description is fine, but the implementation fails. I'm working on it. > > > > > > > > I'm not so sure that documentation was right and implementation wrong. > > > > > > > > What are the reasons of this choice vs. the opposite one? > > > > > > > > Are you sure that for each PCM type is always possible to commit *all* > > > > frames or none? What happens if after a first partial transfer we get an > > > > xrun? > > > > > > We return an error and appl_ptr will be increased with amount of > > > successfully written frames, so we can use this value later for > > > > How you know this amount? > > The appl_ptr is updated inside each plugin after successfull commit to > slave. It's enough.
It's not enough: application does not have access to appl_ptr (and this is a Good Thing). > > > recovery. I think that we should add a new function called (for example) > > > snd_pcm_mmap_commit_partial which will take care about partial > > > transfers as well to allow good recovery. > > > > I don't think it's a good idea... > > > > I've thought more on the problem during this week end and I believe that > > implementation was right before your change and *documentation* should > > had to be changed. > > Unfortunately, the prototype must be also changed, because the return > value of snd_pcm_mmap_commit is 'int' not 'snd_pcm_sframes_t'. Yes, although it's a very little problem, I think. I'd suggest you to revert your changes and fix documentation. -- 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
