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