Re: Suggestion for improving alsa-lib sample rate converters.

[Takashi Iwai <tiwai@suse.de>]

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