A suggestion for better resamplers in alsa.

A suggestion for better resamplers in alsa.

[James Courtier-Dutton]

I have a idea for how we might solve the current resampler problem in alsa.
The current problem is that the resampling is done per period, but the
period size of the application is not always an integer of the hardware
period size. e.g. If the hardware does 48000 Hz and one sets a hardware
period size of 1024. If the application is running at 44100 Hz, the
applications period size will be 940.8, but the period cannot be a
non-integer, so we probably get 940 instead.
One alternative is to have the application's period size vary, so
sometimes it is 940 and other times it is 941. Even with this, the
current resampler code will try to expand 940 samples into 1024, or 941
samples into 1024. Neither of these is perfect. What we really need is
for a given number of input samples, resample to a varying number of
output samples depending on the current sample rate converters filter
history or be pre-warned, at each write, how many application samples
will fill the 1024 hardware period.
Application's runing at 44100 Hz and hardware runing at 48000 Hz is very
common(mp3, CDs) so we really need to find a good solution to this.

The code of interest is:
snd_pcm_sframes_t snd_pcm_mmap_writei(snd_pcm_t *pcm, const void
*buffer, snd_pcm_uframes_t size)
{
        snd_pcm_channel_area_t areas[pcm->channels];
        snd_pcm_areas_from_buf(pcm, areas, (void*)buffer);
        return snd_pcm_write_areas(pcm, areas, 0, size,
                                   snd_pcm_mmap_write_areas);
}

1) If we could get the sample rate conversion done in the
snd_pcm_areas_from_buf() function, we could quite happily vary the
number of output samples from the sample rate converter, ready for
sending to the snd_pcm_write_areas() function.

2) Another solution would be to re-write the snd_pcm_write_areas
function so that it can write samples, but the call would be a multi
stage operation.
I.e. First call a function that returns a value containing the number of
application samples that will be consumed in order to write
1024(hardware period size) samples. This value returned will change
depending on resampler filter history.
The next function will then send exactly the correct number of samples
to the sample rate converter.
The write_areas function tries to write samples one period at a time, so
this (2) option should work quite well. The only disadvantage is that we
will probably have to change the plugin api to acheive this. :-(
As this effectively changes the application period size on each write
operation, we might have to also feed this information back up to the
application for applications that reply on being able to write exactly
one period at a time to the sound card.

In order to port high quality sample rate converts to alsa, I suggest
that we implement it in alsa-lib as floating point operations first.
Once that has been bug fixed, we can then write separate accelerated
interger versions of it. I have found that the rate converters do not
work at all well for 24bit sound samples currently. I.e. Sending 44.1
Khz S32_LE audio to the P16V chip, so it has to get resampled to 48khz
S32_LE first. One just hears horrible noises output.

Any comments?

James



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: A suggestion for better resamplers in alsa.

[Takashi Iwai]

At Fri, 01 Apr 2005 21:58:57 +0100,
James Courtier-Dutton wrote:
> 
> I have a idea for how we might solve the current resampler problem in alsa.
> The current problem is that the resampling is done per period, but the
> period size of the application is not always an integer of the hardware
> period size. e.g. If the hardware does 48000 Hz and one sets a hardware
> period size of 1024. If the application is running at 44100 Hz, the
> applications period size will be 940.8, but the period cannot be a
> non-integer, so we probably get 940 instead.
> One alternative is to have the application's period size vary, so
> sometimes it is 940 and other times it is 941. Even with this, the
> current resampler code will try to expand 940 samples into 1024, or 941
> samples into 1024. Neither of these is perfect. What we really need is
> for a given number of input samples, resample to a varying number of
> output samples depending on the current sample rate converters filter
> history or be pre-warned, at each write, how many application samples
> will fill the 1024 hardware period.
> Application's runing at 44100 Hz and hardware runing at 48000 Hz is very
> common(mp3, CDs) so we really need to find a good solution to this.
> 
> The code of interest is:
> snd_pcm_sframes_t snd_pcm_mmap_writei(snd_pcm_t *pcm, const void
> *buffer, snd_pcm_uframes_t size)
> {
>         snd_pcm_channel_area_t areas[pcm->channels];
>         snd_pcm_areas_from_buf(pcm, areas, (void*)buffer);
>         return snd_pcm_write_areas(pcm, areas, 0, size,
>                                    snd_pcm_mmap_write_areas);
> }
> 
> 1) If we could get the sample rate conversion done in the
> snd_pcm_areas_from_buf() function, we could quite happily vary the
> number of output samples from the sample rate converter, ready for
> sending to the snd_pcm_write_areas() function.

Can this work even if the kernel driver doesn't accept varying samples
per period as it is now?

> 2) Another solution would be to re-write the snd_pcm_write_areas
> function so that it can write samples, but the call would be a multi
> stage operation.
> I.e. First call a function that returns a value containing the number of
> application samples that will be consumed in order to write
> 1024(hardware period size) samples. This value returned will change
> depending on resampler filter history.
> The next function will then send exactly the correct number of samples
> to the sample rate converter.
> The write_areas function tries to write samples one period at a time, so
> this (2) option should work quite well. The only disadvantage is that we
> will probably have to change the plugin api to acheive this. :-(
> As this effectively changes the application period size on each write
> operation, we might have to also feed this information back up to the
> application for applications that reply on being able to write exactly
> one period at a time to the sound card.

IMO, the only "perfect" solution is to change API to allow variable
period sizes.  Otherwise the size mismatch always occurs regardless
what trick you apply.

However, the variable period size would introduce the significant
changes to the core part.  For example, currently the hw/appl pointers
are accumulated until the boundary near to INT_MAX.  The real DMA
buffer position in the ringbuffer is calculated as 'hwptr %
buffer_size'.  With the variable period size, it's no longer true.

Also, for many applications, the variable period size is no preferred
form.  I guess many apps are programmed in a "push" way, to feed the
fixed-size data chunk periodically to the device.  So, we'll face a
problem that JACK has experienced.


> In order to port high quality sample rate converts to alsa, I suggest
> that we implement it in alsa-lib as floating point operations first.
> Once that has been bug fixed, we can then write separate accelerated
> interger versions of it. I have found that the rate converters do not
> work at all well for 24bit sound samples currently. I.e. Sending 44.1
> Khz S32_LE audio to the P16V chip, so it has to get resampled to 48khz
> S32_LE first. One just hears horrible noises output.

I don't think forcing floating point to 16bit samples is a good idea
from performance perspective.  (I don't mean to disagree against
a bettr floating-point operations, though.)
Also, we shouldn't forget the architecture without FP unit.


Takashi


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: A suggestion for better resamplers in alsa.

[Clemens Ladisch]

Takashi Iwai wrote:
> ...
> IMO, the only "perfect" solution is to change API to allow variable
> period sizes.  Otherwise the size mismatch always occurs regardless
> what trick you apply.

This is yet another case of a constant-period-size device, like USB or
ymfpci.

> However, the variable period size would introduce the significant
> changes to the core part.

Maybe we could generalize what usb-usx2y's hwdep does.

> For example, currently the hw/appl pointers are accumulated until
> the boundary near to INT_MAX.  The real DMA buffer position in the
> ringbuffer is calculated as 'hwptr % buffer_size'.  With the
> variable period size, it's no longer true.

But buffer_size would remain constant, wouldn't it?


Regards,
Clemens



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: A suggestion for better resamplers in alsa.

[Takashi Iwai]

At Mon, 4 Apr 2005 17:49:27 +0200 (METDST),
Clemens Ladisch wrote:
> 
> Takashi Iwai wrote:
> > ...
> > IMO, the only "perfect" solution is to change API to allow variable
> > period sizes.  Otherwise the size mismatch always occurs regardless
> > what trick you apply.
> 
> This is yet another case of a constant-period-size device, like USB or
> ymfpci.
> 
> > However, the variable period size would introduce the significant
> > changes to the core part.
> 
> Maybe we could generalize what usb-usx2y's hwdep does.
> 
> > For example, currently the hw/appl pointers are accumulated until
> > the boundary near to INT_MAX.  The real DMA buffer position in the
> > ringbuffer is calculated as 'hwptr % buffer_size'.  With the
> > variable period size, it's no longer true.
> 
> But buffer_size would remain constant, wouldn't it?

I don't think so (in the above, I suppose the input-hwptr on rate
plugin, not the output-hwptr on the real hardware).


Takashi


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: A suggestion for better resamplers in alsa.

[James Courtier-Dutton]

Takashi Iwai wrote:
> At Mon, 4 Apr 2005 17:49:27 +0200 (METDST),
> Clemens Ladisch wrote:
> 
>>Takashi Iwai wrote:
>>
>>>...
>>>IMO, the only "perfect" solution is to change API to allow variable
>>>period sizes.  Otherwise the size mismatch always occurs regardless
>>>what trick you apply.
>>
>>This is yet another case of a constant-period-size device, like USB or
>>ymfpci.
>>
>>
>>>However, the variable period size would introduce the significant
>>>changes to the core part.
>>
>>Maybe we could generalize what usb-usx2y's hwdep does.
>>
>>
>>>For example, currently the hw/appl pointers are accumulated until
>>>the boundary near to INT_MAX.  The real DMA buffer position in the
>>>ringbuffer is calculated as 'hwptr % buffer_size'.  With the
>>>variable period size, it's no longer true.
>>
>>But buffer_size would remain constant, wouldn't it?
> 
> 
> I don't think so (in the above, I suppose the input-hwptr on rate
> plugin, not the output-hwptr on the real hardware).
> 
> 
> Takashi
> 

You are correct, the buffer size on the application side (before
resampling) would not be constant.
If the application sets 44100 Hz, the sound should play 44100 samples
from the application per second. With the current fixed period sizes,
this does not happen, approximations happen at each period, resulting in
a slightly incorrect rate at which 44100 samples are played.

I have yet another possible idea. What about reporting to the
application whether resampling needs to be done at the rate requested by
the application, together with reporting the resulting hardware rate.
The application could then detect when it should maybe try resampling
itself to improve quality. We could then have resampling helper
functions to alsa-lib, that the application could call to do the actual
resampling before it send the samples to the card. In this way the
application will get visibility of the fixed hardware period size, and
make more educated descisions regarding which output rate to use.
This could probably be supported by the addition of a new function call
"snd_pcm_prevent_resampling(...)". This call would be called by the
application just before it calls snd_pcm_set_rate(), and this would
modify the behaviour of the snd_pcm_set_rate() function or just
implement a new function "snd_pcm_set_rate_no_resample()".

We would still want alsa-lib pcm layer to do the sample format
conversion and all the other plugins, just not the problematic resampling.
alsa-lib would then provide a selection of resampling functions that the
application could then use before snd_pcm_writei() or any other form of
mmap transfer.

For example, the application xine has a feature to force a particular
output sample rate, but at the moment, the user has to manually
configure the output sample rate if they wish it to be anything apart
from the sample rate of the media stream. With this new alsa function,
xine could be informed when to use it's own internal resamplers, and
when not to bother, removing the need for the user having to manually
configure the "force_output_sample_rate" setting. But xine would still
wish to send floating point samples to alsa-lib, knowing that alsa-lib
will convert them to 24bit or 16bit depending on the sound card.

James


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: A suggestion for better resamplers in alsa.

[Jaroslav Kysela]

On Tue, 5 Apr 2005, James Courtier-Dutton wrote:

> I have yet another possible idea. What about reporting to the
> application whether resampling needs to be done at the rate requested by
> the application, together with reporting the resulting hardware rate.
> The application could then detect when it should maybe try resampling
> itself to improve quality. We could then have resampling helper
> functions to alsa-lib, that the application could call to do the actual
> resampling before it send the samples to the card. In this way the
> application will get visibility of the fixed hardware period size, and
> make more educated descisions regarding which output rate to use.
> This could probably be supported by the addition of a new function call
> "snd_pcm_prevent_resampling(...)". This call would be called by the
> application just before it calls snd_pcm_set_rate(), and this would
> modify the behaviour of the snd_pcm_set_rate() function or just
> implement a new function "snd_pcm_set_rate_no_resample()".
> 
> We would still want alsa-lib pcm layer to do the sample format
> conversion and all the other plugins, just not the problematic resampling.
> alsa-lib would then provide a selection of resampling functions that the
> application could then use before snd_pcm_writei() or any other form of
> mmap transfer.
> 
> For example, the application xine has a feature to force a particular
> output sample rate, but at the moment, the user has to manually
> configure the output sample rate if they wish it to be anything apart
> from the sample rate of the media stream. With this new alsa function,
> xine could be informed when to use it's own internal resamplers, and
> when not to bother, removing the need for the user having to manually
> configure the "force_output_sample_rate" setting. But xine would still
> wish to send floating point samples to alsa-lib, knowing that alsa-lib
> will convert them to 24bit or 16bit depending on the sound card.

I like this idea. This setup belongs to:

snd_pcm_hw_params_set_rate_noresample()

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: A suggestion for better resamplers in alsa.

[Takashi Iwai]

At Thu, 7 Apr 2005 09:56:48 +0200 (CEST),
Jaroslav wrote:
> 
> On Tue, 5 Apr 2005, James Courtier-Dutton wrote:
> 
> > I have yet another possible idea. What about reporting to the
> > application whether resampling needs to be done at the rate requested by
> > the application, together with reporting the resulting hardware rate.
> > The application could then detect when it should maybe try resampling
> > itself to improve quality. We could then have resampling helper
> > functions to alsa-lib, that the application could call to do the actual
> > resampling before it send the samples to the card. In this way the
> > application will get visibility of the fixed hardware period size, and
> > make more educated descisions regarding which output rate to use.
> > This could probably be supported by the addition of a new function call
> > "snd_pcm_prevent_resampling(...)". This call would be called by the
> > application just before it calls snd_pcm_set_rate(), and this would
> > modify the behaviour of the snd_pcm_set_rate() function or just
> > implement a new function "snd_pcm_set_rate_no_resample()".
> > 
> > We would still want alsa-lib pcm layer to do the sample format
> > conversion and all the other plugins, just not the problematic resampling.
> > alsa-lib would then provide a selection of resampling functions that the
> > application could then use before snd_pcm_writei() or any other form of
> > mmap transfer.
> > 
> > For example, the application xine has a feature to force a particular
> > output sample rate, but at the moment, the user has to manually
> > configure the output sample rate if they wish it to be anything apart
> > from the sample rate of the media stream. With this new alsa function,
> > xine could be informed when to use it's own internal resamplers, and
> > when not to bother, removing the need for the user having to manually
> > configure the "force_output_sample_rate" setting. But xine would still
> > wish to send floating point samples to alsa-lib, knowing that alsa-lib
> > will convert them to 24bit or 16bit depending on the sound card.
> 
> I like this idea. This setup belongs to:
> 
> snd_pcm_hw_params_set_rate_noresample()

This feature would be nice especially also for the sound servers which
do resampling by themselves.


Takashi


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: A suggestion for better resamplers in alsa.

[James Courtier-Dutton]

Takashi Iwai wrote:
>>
>>I like this idea. This setup belongs to:
>>
>>snd_pcm_hw_params_set_rate_noresample()
> 
> 
> This feature would be nice especially also for the sound servers which
> do resampling by themselves.
> 

Ok, so how do we actually implement it. We need to be able to detect the
presence or absence of this function by the application at run time.
We can't exactly have an application call this function against an older
version of the lib that does not contain it.
I will look into adding the function anyway, and we can worry about the
runtime detection problem later.

James


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: A suggestion for better resamplers in alsa.

[Jaroslav Kysela]

On Sun, 10 Apr 2005, James Courtier-Dutton wrote:

> Takashi Iwai wrote:
> >>
> >>I like this idea. This setup belongs to:
> >>
> >>snd_pcm_hw_params_set_rate_noresample()
> > 
> > 
> > This feature would be nice especially also for the sound servers which
> > do resampling by themselves.
> > 
> 
> Ok, so how do we actually implement it. We need to be able to detect the
> presence or absence of this function by the application at run time.
> We can't exactly have an application call this function against an older
> version of the lib that does not contain it.
> I will look into adding the function anyway, and we can worry about the
> runtime detection problem later.

I just tried to implement this function. Please, could you test 
snd_pcm_hw_params_set_rate_resample() function (in current CVS)?

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: A suggestion for better resamplers in alsa.

[James Courtier-Dutton]

Jaroslav Kysela wrote:

>I just tried to implement this function. Please, could you test 
>snd_pcm_hw_params_set_rate_resample() function (in current CVS)?
>
>						Jaroslav
>  
>
Why not s/resample/no_resampling/  ?

I.e. There should really be the word "no" in there somewhere because we 
are asking for no resampling to take place.

I assume this is called before one calls snd_pcm_set_rate()  ?

If I get time, I will try to test this tonight.

James




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: A suggestion for better resamplers in alsa.

[Jaroslav Kysela]

On Tue, 12 Apr 2005, James Courtier-Dutton wrote:

> Jaroslav Kysela wrote:
> 
> >I just tried to implement this function. Please, could you test 
> >snd_pcm_hw_params_set_rate_resample() function (in current CVS)?
> >
> >						Jaroslav
>
> Why not s/resample/no_resampling/  ?
> 
> I.e. There should really be the word "no" in there somewhere because we 
> are asking for no resampling to take place.

The parameter is on/off switch, so I think that it's better to use 0 = 
disable and 1 = enable (default) than an inverted logic.

> I assume this is called before one calls snd_pcm_set_rate()  ?

Yep.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click