On Fri, 13 Jun 2008, Takashi Iwai wrote: > > > Ditto, or we may reuse snd_pcm_hw_params_fifo_size()? > > > > Yes, fifo_size was designed to announce possible extra latency to > > applications. > > On the second thought, it's better *not* to query this value as > hw_params. The latency may be variable. And the word "FIFO" isn't > appropriate in every case. > > And, above all, reviving an old API is bad... This value should define maximum latency - not actual latency. snd_pcm_delay() should give actual overall latency to apps. > > I think that the current PCM API concept is tightly period based. You > > cannot change it easily. It would be probably better to move to > > "byte-stream" in next revision of PCM API. > > Not that difficult, I guess, from API POV. The major work is in the > PCM core part and some alsa-lib plugins. But, it's not API. > > What I once worked on is an extra timinig queue. Suppose that we > provide an API to access a timing queue that holds the wake-up > schedule, either in time or sample unit. The poll / read / write > syscalls are woken up at the time of this schedule. In the case of > period model, it means that the queue is automatically filled up with > a constant period. If app wants to schedule by itself, it can use > this queue manually. (Of course, this means that the timing queue > must be filled before starting the stream.) It look like more complicated sleep_min implementation we already had: http://git.alsa-project.org/?p=alsa-kernel.git;a=commit;h=31e8960b35975ed235d283d6fb95d0e28dffded0 Jaroslav ----- Jaroslav Kysela <perex@xxxxxxxx> Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
