Suggestion for improving alsa-lib sample rate converters.

Suggestion for improving alsa-lib sample rate converters.

[James Courtier-Dutton]

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?

James


-------------------------------------------------------
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

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

[Takashi Iwai]

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

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

[Clemens Ladisch]

James Courtier-Dutton wrote:
> 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.

Some hardware (ymfpci, USB, Firewire) actually has varying period
sizes, too; it would be nice to allow application to know this.

AFAICS in all these cases, the period _time_ is not an integer
multiple of the sample time, but it's constant.

> 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.

IIRC the ymfpci driver doesn't know the exact period size because the
hardware SRC chooses when to interrupt.  (ymfpci chips always use a
fixed period time of 256/48000 seconds.)

> 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);

And an equivalent _get_last_period_size() for recording.

> With this extra bit of information fed back to the application, we could
> implement proper polyphase interpolators in alsa-lib.

This doesn't look backwards compatible.  I guess we have to emulate
constant periods (like the drivers above do) for applications that
don't have enabled this.


Regards,
Clemens



-------------------------------------------------------
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

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

[Takashi Iwai]

At Wed, 15 Sep 2004 18:02:18 +0200 (METDST),
Clemens Ladisch wrote:
> 
> > With this extra bit of information fed back to the application, we could
> > implement proper polyphase interpolators in alsa-lib.
> 
> This doesn't look backwards compatible.  I guess we have to emulate
> constant periods (like the drivers above do) for applications that
> don't have enabled this.

Hmm, it sounds doable.  Maybe the old-style workaround can be
implemented in alsa-lib and OSS emulation module.


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