[pulseaudio-discuss] how to set buffer attributes in 0.9.15

[Tanu Kaskinen]

On Thu, 2011-04-21 at 22:48 -0700, sohail abbasi wrote:
> 
> hi everyone,
> 
> 
> 
> I am stuck in the pulseaudio programing, I am adding pulseaudio support
> in my existing application.Design of the application is synchronous and
> multithreaded. I need exactly 320 samples  (320*4 bytes) for reading
> and writing. While using pulseaudio 0.9.14 , below parameters works
> fine but with 0.9.15  readablesize is not as expecting :( .

If 0.9.14 worked as you want, the switch to timer-based scheduling
probably caused the change in behavior. If this application is used only
on systems where you can dictate the pulseaudio daemon settings, then
adding "tsched=0" to the line in /etc/pulse/default.pa where
module-hal-detect is loaded may help.

If you can't control the pulseaudio configuration of your users, then I
believe you can't get the behavior anymore that you got with 0.9.14.
According to the documentation, the fragsize buffer attribute should do
what you want for capture streams, but apparently that's not the case in
practice (based on what you've told - I haven't done any tests myself).

Does anyone know what fragsize actually does? Does it have any meaning
anymore? The documentation should be fixed...

I'm fairly sure that you are able to fake fixed-size fragments in your
pulseaudio support code, though. Just buffer the data locally, and
transfer only 320 at a time with the rest of the application.

> One more
> thing , are playattributes and record attributes related to each other
> or have any effect on one another ?

No, they don't have any effect on each other.

> 
> ***************
> 
> PLAYBACK ATTRIBUTES:
> 
>     play_attributes = (pa_buffer_attr*) malloc (sizeof (pa_buffer_attr));
> 
>      play_attributes->maxlength =  pa_usec_to_bytes(21*PA_USEC_PER_MSEC,&_sample_spec);

This doesn't seem like a good idea. Maxlength doesn't affect the request
size. What does 21 ms mean anyway? How many samples is it?

>      play_attributes->tlength = (uint32_t) -1;
> 
>      play_attributes->prebuf = 0;
> 
>        play_attributes->fragsize = pa_usec_to_bytes (20 * PA_USEC_PER_MSEC, &_sample_spec);

Fragsize is only for capture streams. It doesn't have any meaning for
playback streams. See
http://0pointer.de/lennart/projects/pulseaudio/doxygen/structpa__buffer__attr.html

>         play_attributes->minreq = (uint32_t) -1;

If you set the PA_STREAM_EARLY_REQUESTS, you can use minreq to get
requests of some constant size, like you seem to want to do. See the
flag description at
http://0pointer.de/lennart/projects/pulseaudio/doxygen/def_8h.html#a6966d809483170bc6d2e6c16188850fc

> 
> ****************
> 
> RECORD ATTRIBUTES:
> 
> 
> 
> record_attributes = (pa_buffer_attr*) malloc (sizeof (pa_buffer_attr));
> 
>  record_attributes->maxlength = pa_usec_to_bytes (21 * PA_USEC_PER_MSEC, &_sample_spec); 

Set maxlength to -1 here too.

>         record_attributes->tlength = (uint32_t) -1;

tlength doesn't have any effect on capture streams (-1 is probably a
fine initialization value, though).

>         record_attributes->prebuf = (uint32_t) 0;

Prebuf doesn't have any effect on capture streams either.

>         record_attributes->fragsize = pa_usec_to_bytes (20 * PA_USEC_PER_MSEC, &_sample_spec);

Is your samplerate 16 kHz?

>          record_attributes->minreq =pa_usec_to_bytes(1*PA_USEC_PER_SEC,&_sample_spec);

Minreq doesn't have any effect on capture streams.

-- 
Tanu