From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: Re: [PATCH] emu10k1: add interval timer support Date: Fri, 24 Sep 2004 17:13:11 +0200 Sender: alsa-devel-admin@lists.sourceforge.net Message-ID: References: <200409241453.i8OErtVR029650@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: <200409241453.i8OErtVR029650@localhost.localdomain> Errors-To: alsa-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Paul Davis Cc: Jaroslav Kysela , Lee Revell , alsa-devel List-Id: alsa-devel@alsa-project.org At Fri, 24 Sep 2004 10:53:55 -0400, Paul Davis wrote: > > >On Fri, 24 Sep 2004, Takashi Iwai wrote: > > > >> > How would I open only channels 10 and 11 with one app and 1-6 with > >> > another using a single 16 channel device? > >> > >> It's doable to implement the multi-channel non-interleaved PCM with > >> multi open. But even in this case, we provide eventually 16 > >> substreams, so perhaps providing 16 mono substreams would be easier to > >> implement (at least for the kernel driver). > >> > >> Regarding the efficiency (latency), there will be no difference > >> between the multi-channel and multi-substream implementations. > >> In the latter case, we can use linked substreams, as you already > >> mentioned. > > > >I don't understand much the requirement. If you want to use other ALSA > >(legacy) applications, you can reroute them to appropriate FX bus only. > >The controls are already available. > > > >The multichannel PCM should be best only for multichannel recording / > >playback. You're trying to desing a new API which does not make much > >sense. > > more to the point, perhaps, is that the very first implementation of > the RME Hammerfall (digi9652) driver that i did took lee's approach > and when we measured it, there was a very definite performance > hit. having to call the "elapsed" function for every mono stream added > measurable overhead. when we collapsed it back to a single > non-interleaved, 26 channel device, it was significantly more > efficient. It's a good point. If you use the timer-style irq, the perfomance decrease would be smaller, though, because you don't (can't) get irqs per PCM stream. However, the overhead must still exist. Takashi ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php