From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: Problem with RME 9632 and Plug Date: Wed, 04 Aug 2004 13:15:49 +0200 Sender: alsa-devel-admin@lists.sourceforge.net Message-ID: References: <200408040018.i740ITg5017942@localhost.localdomain> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: Errors-To: alsa-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Jaroslav Kysela Cc: Paul Davis , Ed Wildgoose , alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.org At Wed, 4 Aug 2004 12:56:28 +0200 (CEST), Jaroslav wrote: > > On Wed, 4 Aug 2004, Takashi Iwai wrote: > > > Well, HDSP needs at least 14 non-interleaved channels, so we'll need > > anyway the conversion for normal apps like mplayer. Then no external > > timinig source would be needed. > > I don't undestand this. As far as I know, RME cards have 64kB ring buffer > for all voices and the two periods constraint is for all voices. Thus > there is no correlation between the used channel count and period size. > The timing is same. I mean, we need anyway convert the format and the interleave -> non-interleave in this case. In comparison with this, introducing an intermedate buffer with an arbitrary size doesn't influence on the performance so much. I don't think to do this in plug as default. But it would be nice to have this layer for devices with the limited periods and/or buffer size (of course only if the extra data transfer doesn't matter). Takashi ------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com