[alsa-devel] alsa-plugin: rate-libsamplerate, buffer shrinkage problem

[Takashi Iwai]

At Thu, 08 Jan 2009 09:39:14 -0800,
John L. Utz III wrote:
> 
> Hi;
> 
> Our legacy product code is tormenting me again. :-(
> 
> i have a 3rd party sound-fiddling library that only works with an 8k 
> buffer. the company that wrote it is long gone. i cant change this.
> 
> i have a enourmous array of content that is coded at 44.1K. i cant 
> change this.
> 
> i have to use a cheap soundblaster audigy card (ca0106) that only 
> supports 48K. it sounds really good at 48K, so it seems like a winner.
> 
> the samplerate plugin is almost perfect for helping me successfully use 
> the 48K only card with our 44.1K content.
> 
> *almost*. :-(
> 
> if i use the samplerate plugin thusly in my CA0106.conf:
> 
> CA0106.pcm.front.0 {
>          @args [ CARD  ]
>          @args.CARD {
>                  type string
>          }
> #        type hw
> #        card $CARD
>          type rate
>          slave {
>          pcm "hw:0,0"
>          rate 48000
>          }
>          converter "samplerate"
> }
> 
> 
> I no longer get a 8192 byte buffer, i get a 7526 byte buffer. :-(
> 
> snd_pcm_hw_params_set_buffer_size_near() fails if i try and set it to 
> 8192, but it accepts 7526 or 15092.

8192 * 44100 / 48000 = 7526

The hardware uses the period size 8192, but because of the rate
conversion it's also changed to that value.

> I *assume* that either the samplerate plugin or libsamplerate are 
> consuming part of the buffer for the resample job. Not at all unreasonable.
> 
> But it seems like i should be able to bump up the internal working 
> buffer size so that i get my 8192 byte submittal buffer back.

The period size is the size of wake-up (a sort of).
If the hardware can't accept the arbitrary size, you can't set it,
too.  Even if you an internal buffer to absorb the size difference,
you'll still have the problem when and how to wake up the process.


Takashi