[pulseaudio-discuss] introduce the new feature of ring buffer log and ask for comments

[Arun Raghavan]

On Tue, 2012-08-14 at 16:36 +0800, rong deng wrote:
> 2012/8/14 David Henningsson <david.henningsson at canonical.com>:
> > On 08/14/2012 08:19 AM, rong deng wrote:
> >>
> >> Hi David,
> >>
> >> Thanks for your comments, see my inlined comments below:
> >>
> >> 2012/8/14 David Henningsson <david.henningsson at canonical.com>:
> >>>
> >>> On 08/13/2012 04:59 PM, rong deng wrote:
> >>>>
> >>>>
> >>>> Ask for comments
> >>>> ================
> >>>>
> >>>> We design this feature to try to be useful for users and developers.
> >>>> We'd
> >>>> like
> >>>> to hear from you how do you think. Please don't hesitate to give your
> >>>> valuable
> >>>> feedback!
> >>>
> >>>
> >>>
> >>> Hmm, maybe we could add the output of "pactl log" to bugs reported
> >>> against
> >>> the PulseAudio package in Ubuntu? That way maybe we don't have to ask for
> >>> PulseAudio logs all the time...so yes, then it could be helpful!
> >>
> >>
> >> Yes, this is one of our goals. In this way, developers only ask users
> >> to give the output of 'pactl log', users don't bother to kill
> >> PulseAudio and restart the daemon with somewhat verbose options.
> >
> >
> > Restarting PA is not necessary as "pacmd set-log-level" and "pacmd
> > set-log-target" (?) exist.
> 
> Technically speaking, these two commands can do this functionality.
> But with the following cons:
> 
> 1. Users have to set the log level and log target back to the original
> later. IIRC, there's no easy way to know what the current log level
> and log target are right now, so users have no idea what to set to.
> Users can choose not to change it back, but then, with a lot of noisy
> log...
> 2. Changing it to something else interrupts the normal logging
> process. e.g. you're logging to a file and then suddenly the middle
> part is missing from the file. It's not OK to investigate for later
> purposes.
> 
> So here comes this new feature, a) not clobber the original logging
> process, b) helps to gather debugging information easily.

More importantly, the idea is for the ringbuffer to log _everything_,
independently of the log-level. So if something goes wrong (mostly drops
or the like), you have a full log till some time in the past. I don't
know how feasible this is, but maybe in case of a SEGV, we can pull this
information from a core file? Should be doable by prefacing each
ringbuffer region with some magic string.

-- Arun