At Fri, 13 Jun 2008 17:44:24 +0200 (CEST), Jaroslav Kysela wrote: > > 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 Yes and no. Yes, it updates with a system timer. No, it's not bound with the period like the current framework. The point is that the wake-up timing isn't defined as constant but via a timing queue (or a request queue). This is more suitable for pull-style apps like JACK. Which irq source is used doesn't matter. Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
