From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: Suggestion for improving alsa-lib sample rate converters. Date: Wed, 15 Sep 2004 18:00:19 +0200 Sender: alsa-devel-admin@lists.sourceforge.net Message-ID: References: <414853EC.3050103@superbug.co.uk> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Return-path: Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by alsa.alsa-project.org (ALSA's E-mail Delivery System) with ESMTP id 645422FE for ; Wed, 15 Sep 2004 18:01:15 +0200 (MEST) In-Reply-To: <414853EC.3050103@superbug.co.uk> Errors-To: alsa-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: James Courtier-Dutton Cc: alsa-devel@alsa-project.org List-Id: alsa-devel@alsa-project.org At Wed, 15 Sep 2004 15:38:36 +0100, James Courtier-Dutton wrote: > > The ideal sample rate converter would be a serial sample rate converter. > e.g. Each sample is fed into the converter, and the new samples exit the > converter at the correct rate. > With alsa this would convert to user application calling snd_pcm_write() > with X samples, and Y samples coming out of the rate converter. > But one cannot have half a sample, so some rounding has to happen, so > for X input samples, the output will differ depending on what went > before, so one might get Y samples coming out, or Y+1 samples coming out. > > User applications require a number of things from the sound card. > 1) How many samples will fill the next period. > 2) When doing sample rate conversions, this period size that the app > sees should really be allowed to be different for each period. > > Currently, we are limited in that the user application's period size has > to be the same size for all periods. > > The hardware normally has all equal size periods per buffer. > Depending on the state of the sample rate converters, this "all periods > the same size" at the hardware level will result in varying period sizes > at the application level after the sample rate converters have acted. > E.g. Hardware running at 48000, with period size of 1024. > Application running at 44100, period sizes, in sequence might be > 941,941,941,941,940,941,941,941,941,940... > I.e. every 5th period having a different size. > > If the application wishes to write whole periods at a time(e.g. Mem > mapped, or callback based apps), there will have to be a way to tell the > application about the size of the next period. > > Conclusion: > So, the alsa application would now do: > x = snd_pcm_get_next_period_size(); /* This would be a new api call */ > snd_pcm_write(x samples); > > With this extra bit of information fed back to the application, we could > implement proper polyphase interpolators in alsa-lib. > > Any comments? A similar problem persists also in the isochronos transfer like USB audio. So, in general, it'd be nice to have a variable period size. ... of course, the biggest and the only problem is the compatibility :) I guess JACK can accept the variable period size concept although the current model doesn't support it. Obviously the callback style is easier to handle this kind of cases than the push style. Takashi ------------------------------------------------------- This SF.Net email is sponsored by: thawte's Crypto Challenge Vl Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam Camcorder. More prizes in the weekly Lunch Hour Challenge. Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m