From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: Lowest latency: JACK, or ALSA directly? Date: Wed, 17 Nov 2004 19:28:46 +0100 Message-ID: References: <20041111144152.GA12443@stud.ntnu.no> <87mzxozahr.fsf@sulphur.joq.us> <20041112090416.GA3167@stud.ntnu.no> <87oei3xbly.fsf@sulphur.joq.us> <87k6srx9wi.fsf@sulphur.joq.us> <87oehwv0tc.fsf@sulphur.joq.us> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: <87oehwv0tc.fsf@sulphur.joq.us> Sender: alsa-devel-admin@lists.sourceforge.net Errors-To: alsa-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Jack O'Quin Cc: =?ISO-8859-1?Q?Asbj=F8rn_S=E6b=F8?= , alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.org At 17 Nov 2004 11:32:15 -0600, Jack O'Quin wrote: > > > > > Takashi Iwai writes: > > > > I'm asking this because some boards (e.g. RME32/96) have the fixed > > > > buffer size, and can't take the configuration as two periods per > > > > buffer. IIRC, JACK fills all the buffer at the first sequence, and > > > > this results in the higher latency than necessary. > > > > > > > > Correct me if I'm wrong. > > > At 12 Nov 2004 11:19:25 -0600, > > Jack O'Quin wrote: > > > I believe you are correct about this. You probably understand it > > > better than I do. :-) > > > > > > Is this something we could fix in JACK's ALSA driver backend? > > Takashi Iwai writes: > > We can set different values to avail_min for playback and capture > > directions. For getting the minimal latency, set > > (nperiods - 1) * period_size for playback and period_size for > > capture. > > > > The patch attached adds a new option -f to specify the filling > > periods. As default (= 0), it's identical with nperiods, so the old > > behavior is kept. > > Thanks for the patch! > > Not sure I completely understand how to document this. Is -f > effectively setting the output latency, with -n as the default? Well, it's so just because I didn't want to break the compatible behavior. With this model, basically the number of periods in the buffer doesn't mean the latency at all but is required just for the stream configuration. The required condition is only nperiods >= 2. So, this option isn't even necessary if we query the nearest buffer size to "f-val * period_size". Maybe this would be a better implementation from the perspective of usability. The playback latency is defined with -f option (the capture latency is always minimal). The minival value is 2. Larger value means more robustness. For example, on some boards with the unreliable interrupt handling (like ymfpci), one should set bigger than 2. As mentioned, its default is as same as -n value, corresponding to the _maximal_ latency. It's just for compatibility. It's fine to set this default to 2 if you think it's better. > Is there some way users could just set the desired latency directly, > or even request the minimum number of periods? Is the minimum always > 2? What happens if the user specifies -f1? 2 periods (i.e. double buffer) are effectively the minimal latency. The -f option doesn't acccept less than 2 or bigger than -n. Takashi ------------------------------------------------------- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8