[pulseaudio-discuss] Google ChromeOS reinventing the wheel, ignoring PulseAudio

[Dylan Reid]

On Fri, Oct 7, 2011 at 7:03 AM, <pierre-louis.bossart at linux.intel.com>wrote:

> >
> >  I've attached the PA config files I am using, along with the log
> > output(pulselog).  The most suspicious thing in there is the failure to
> > get
> > RT scheduling.  Is there something obviously wrong with the configs that
> > would cause these numbers to be so high, or to prevent 10ms latency
> > working?
>
> Hi Dylan,
> Yes, without real-time scheduling it's unlikely that you would get
> low-latency results. in your setup, everything is based on system timers
> with ALSA interrupts disabled, if there's a delay in handling timer events
> chances are you will see underruns, which results in a  latency increase.
> Is there any reason why this would fail on Chrome, usually this is only a
> configuration issue?
>

This is just a configuration issue, I'll have to set up permissions for the
default user to change setrlimit rtprio.  I'll give that a try and see what
happens.

>
> Looking at your log file, I think there's an issue with the buffer
> settings. The requested latency is 20ms (tlength, total buffering), but at
> the same time the minreq field is also set to 20ms. Minreq defines the
> amount of data requested by PulseAudio to the client. You would think that
> a double-buffering scheme is needed here. If the two values are equal, I
> am not sure things would work well? Chances are that you fell in a corner
> case where PulseAudio corrects the values you set to have the latency at
> least twice the minreq value?
>
Makes sense, I'll take a look at what pacat is actually filling the buffer
attributes with and see if I can track this down.

>
> Also in default.pa you load the alsa-sink/source by hand yet use
> module-detect. This looks odd, it's either one or the other?
>
hand loading was just a quick hack to avoid using the alsa "default"
interface which was going through dmix and wasting cycles.  It's weird but I
don't think it should hurt performance once it's up and running.

thanks for the help Pierre,

Dylan

> -Pierre
>
>
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20111007/59c675af/attachment-0001.htm>