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

[rong deng]

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.

>
>
>>> 3) How long is the per-thread buffer by default (and is that in messages
>>> or
>>> characters)? Would it make sense to have this limit configurable (in what
>>> ways)?
>>
>>
>> For each thread, it contains 200 log messages with each message at
>> most 512 characters. As in the current implementation these numbers
>> are hard coded. It's doable to make it configurable, but it would
>> complicate the current code a lot. And it's best to configure it at
>> run time.
>
>
> Hmm. This means different threads will look back different lengths of time,
> e g, if thread A logs something once every second and thread B logs every 10
> ms, that would mean pactl log would be something like:
>
> 198 msgs from thread A,
> 100 msgs from thread B,
> 1 msg from thread A,
> 100 msgs from thread B,
> 1 msg from thread A.
>
> Perhaps it will be confusing that people will see the first 198 msgs from
> thread A without seeing the thread B messages in between?

Hmm, the output is more clever. Each message would have its timestamp,
and the only the latest 200 messages (well, the number could be
changed) are shown to user. So the answer to your question is: it
depends on the time of each message from each thread.

e.g.
t1: 198 msgs from thread A,
t2: 100 msgs from thread B,
t3: 1 msg from thread A,
t4: 100 msgs from thread B,
t5: 1 msg from thread A.

For simplicity, let's assume all 198 messages have the same time
stamp, so does thread B.

then according to our rule, the messages shown would be:
t2's latest 98 messages from thread B
t3's 1 message from thread A
t4's 100 messages from thread B.
t5's 1 message from thread A.

Hope this clarifies a bit.

Thanks!