Jaroslav Kysela wrote: > > On Sat, 22 Feb 2003, Abramo Bagnara wrote: > > > Jaroslav Kysela wrote: > > > > > > Hello all, > > > > > > I'd like to announce a new PCM API extension. Although it is > > > implemented, it might be changed following the discussion on this list. > > > I've added the snd_pcm_forward() function. This function is > > > function with opposite meaning to snd_pcm_rewind() - it skips given count > > > of frames (note that in the ring buffer are unchanged, only the r/w > > > pointer is increased). The application has full control on the r/w pointer > > > now. It's useful mainly in the no-xrun mode where the stream runs forever. > > > > Don't we had already snd_pcm_reset for exactly the same purpose? > > Yes and no. You cannot fill the buffer ahead without writting some > samples. I think that it's not bad to offer the full control on appl_ptr.
"You cannot fill the buffer without writing some samples?" ??? I don't understand what you mean. > It doesn't cost us anything and I can imagine some special applications Apart that we have better things to do than to design solutions searching for problem to solve. Is not better to wait for the true problem(s) to show up and then try to design the better solution for a definite class of problems? > where the buffer is auto-silenced that they need to write samples into the > specific position. Reset is nice, but you cannot tell the count of frames > to be skipped without filling. However I think that auto-silence is not the best thing we've designed. We're using an interrupt handler to do what a rt-like user space process should do. We'd have many things that might be solvable (like saturation in dmix by example) in this way, but we've (rightly) choosen not to do it to respect the general principle "never do in kernel space what is doable in user space". Sometimes I think that auto silence is an unfortunate exception and I'd prefer we'd try to move in the opposite direction. > I'm also going to propose next extension: Actually, the appl_ptr managing > routines - snd_pcm_reset(), snd_pcm_rewind(), snd_pcm_forward() always > uses an ioctl for it's operation. I think that it wouldn't be a bad idea > to implement these function in the lightweight variant, too. I mean that > they will operate only with the actual hw_ptr without calling the kernel > code. We have already functions to synchronize the hw_ptr with the > hardware (snd_pcm_delay(), snd_pcm_hwsync()). Because it's late to change > this behaviour in alsa-lib, I propose to create a function > 'snd_pcm_fast_rw_change()' (better name?) which tells the alsa-lib that no > accurate operation is required. Especially lowlatency applications will > benefit that we removed more 'user<->kernel' switches. Note that the assumption of monotonic direction of appl_ptr is spread everywhere so I doubt that this is feasible for snd_pcm_rewind. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ------------------------------------------------------- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
