Dropouts due to CPU meter? #10
Comments
|
Can you be more specific? The load is only computed once every two seconds
best
j
2017-02-12 20:31 GMT+01:00 andimik <[email protected]>:
… It seems never versions produce drop-out after inserting the CPU meter.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#10>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AITzwCxmHlOhNF9UidGVmleJM9HM-0GSks5rb14CgaJpZM4L-lhx>
.
--
Jan van Katwijk
+31 (0)15 3698980
+31 (0) 628260355
|
|
I've tested it again. Seems playback from an sdr file caused that strange dropout. I can reproduce them (older version no dropout, newer with) You could try to load an sdr file, probably with the samples I sent you from Slovenia. Very funny, there are absolutely no dropouts when I press the "audio" button, write a wav-file and listen to that. |
|
I do not have dropouts,
best
j
2017-02-13 22:18 GMT+01:00 andimik <[email protected]>:
… I've tested it again. Seems playback from an sdr file caused that strange
dropout. I can reproduce them (older version no dropout, newer with)
You could try to load an sdr file, probably with the samples I sent you
from Slovenia.
Very funny, there are absolutely no dropouts when I press the "audio"
button, write a wav-file and listen to that.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#10 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AITzwI0v67nFGpycDGCabda484rHZ3Euks5rcMikgaJpZM4L-lhx>
.
--
Jan van Katwijk
+31 (0)15 3698980
+31 (0) 628260355
|
|
I can it confirm too, sound dropouts occurs randomly qt-dab, old sdr-j works without dropouts. |
|
What is the cp load when these dropouts happen. In my case the cpuload is
app 20% and I do not notice dropouts
J
2017-02-15 13:48 GMT+01:00 zygmund2000 <[email protected]>:
… I can it confirm too, sound dropouts occurs randomly qt-dab, old sdr-j
works without dropouts.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#10 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AITzwOfmC0lwRQIRDNicsFzVKWq1yKssks5rcvQCgaJpZM4L-lhx>
.
--
Jan van Katwijk
+31 (0)15 3698980
+31 (0) 628260355
|
|
CPU load is low all time, this droputs are not related to CPU load, looks like audio speed don't match to soundcard speed or something like this, because sound doesn't stop but changes/skips time. |
|
You had a remark on drop outs of sound.
There are a few possibilities that can cause drop outs in sound.
a. if the DAB+ frames have crc errors than, obviously, the containing data
is discarded and the frames - for a DAB+ frame 120 msec -
do not contribute to the output.
b. if the audio units in the DAB frames contain errors, then the
contribution of such an audio unit (24 msec) is discarded
c. if the clock on the soundcard differs from the clock in the input
device, then it might happen that soundframes are either "early"
or "late" arriving at the sound engine.
d. the software driving the soundcard is slow and needs a particular
buffersize for a continuous soundstream.
a) and b) happen, but that shows on the markers on the technical data
widget.
c. might happen, but unless the difference is large, the effect sould be
limited
d. happens from time to time. I instrumented my code with a counter telling
how many samples were missing with different buffersizes
On my RPI this happens when the buffersize is too small,
On my laptop this happens - with a dropout of 24 msec on say every 15
seconds - with too small or too large a buffersize
The parameter here is the setting of the latency, a parameter that can be
set in the .ini file. On my laptop a value 1 or 2 gives as result
no noticeable dropout - provided they are not caused by earlier mentioned
reasons - when running files or input over minutes
Setting the latency parameter to 0, i.e. a buffersize indicated as 0, such
that the underlying sound engine will define its own size,
gives dropouts, app 24 msec in about 15 seconds.
My suggestion is to experiment a little with the latency parameter, and if
needed I can create a version with a smaller
increment in buffersize for higher latency values (one issue on my laptop
is that the default setting for all kinds of Latency
in the portaudio module that I am using is 0 in all cases, so I "invented"
my own buffersize).
best
jan
2017-02-15 14:23 GMT+01:00 zygmund2000 <[email protected]>:
… CPU load is low all time, this droputs are not related to CPU load, looks
like audio speed don't match to soundcard speed or something like this,
because sound don't stop but change time.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#10 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AITzwC5lzpCEt74X2s6Yl-pIwrcZzq3Iks5rcvxhgaJpZM4L-lhx>
.
--
Jan van Katwijk
+31 (0)15 3698980
+31 (0) 628260355
|
|
Just add line to qt-dab.ini latency=1?
On 16.02.2017 13:02, JvanKatwijk wrote:
You had a remark on drop outs of sound.
There are a few possibilities that can cause drop outs in sound.
a. if the DAB+ frames have crc errors than, obviously, the
containing data
is discarded and the frames - for a DAB+ frame 120 msec -
do not contribute to the output.
b. if the audio units in the DAB frames contain errors, then the
contribution of such an audio unit (24 msec) is discarded
c. if the clock on the soundcard differs from the clock in the
input
device, then it might happen that soundframes are either "early"
or "late" arriving at the sound engine.
d. the software driving the soundcard is slow and needs a
particular
buffersize for a continuous soundstream.
a) and b) happen, but that shows on the markers on the technical
data
widget.
c. might happen, but unless the difference is large, the effect
sould be
limited
d. happens from time to time. I instrumented my code with a
counter telling
how many samples were missing with different buffersizes
On my RPI this happens when the buffersize is too small,
On my laptop this happens - with a dropout of 24 msec on say every
15
seconds - with too small or too large a buffersize
The parameter here is the setting of the latency, a parameter that
can be
set in the .ini file. On my laptop a value 1 or 2 gives as result
no noticeable dropout - provided they are not caused by earlier
mentioned
reasons - when running files or input over minutes
Setting the latency parameter to 0, i.e. a buffersize indicated as
0, such
that the underlying sound engine will define its own size,
gives dropouts, app 24 msec in about 15 seconds.
My suggestion is to experiment a little with the latency
parameter, and if
needed I can create a version with a smaller
increment in buffersize for higher latency values (one issue on my
laptop
is that the default setting for all kinds of Latency
in the portaudio module that I am using is 0 in all cases, so I
"invented"
my own buffersize).
best
jan
2017-02-15 14:23 GMT+01:00 zygmund2000
<[email protected]>:
CPU load is low all time, this droputs are not related to CPU
load, looks
like audio speed don't match to soundcard speed or something
like this,
because sound don't stop but change time.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#10 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AITzwC5lzpCEt74X2s6Yl-pIwrcZzq3Iks5rcvxhgaJpZM4L-lhx>
.
…--
Jan van Katwijk
+31 (0)15 3698980
+31 (0) 628260355
—
You are receiving this because you commented.
Reply to this email directly, view
it on GitHub, or mute
the thread.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/JvanKatwijk/qt-dab","title":"JvanKatwijk/qt-dab","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/JvanKatwijk/qt-dab"}},"updates":{"snippets":[{"icon":"PERSON","message":"@JvanKatwijk in #10: You had a remark on drop outs of sound.\nThere are a few possibilities that can cause drop outs in sound.\na. if the DAB+ frames have crc errors than, obviously, the containing data\nis discarded and the frames - for a DAB+ frame 120 msec -\ndo not contribute to the output.\nb. if the audio units in the DAB frames contain errors, then the\ncontribution of such an audio unit (24 msec) is discarded\nc. if the clock on the soundcard differs from the clock in the input\ndevice, then it might happen that soundframes are either \"early\"\nor \"late\" arriving at the sound engine.\nd. the software driving the soundcard is slow and needs a particular\nbuffersize for a continuous soundstream.\n\na) and b) happen, but that shows on the markers on the technical data\nwidget.\nc. might happen, but unless the difference is large, the effect sould be\nlimited\nd. happens from time to time. I instrumented my code with a counter telling\nhow many samples were missing with different buffersizes\n On my RPI this happens when the buffersize is too small,\n On my laptop this happens - with a dropout of 24 msec on say every 15\nseconds - with too small or too large a buffersize\n\nThe parameter here is the setting of the latency, a parameter that can be\nset in the .ini file. On my laptop a value 1 or 2 gives as result\nno noticeable dropout - provided they are not caused by earlier mentioned\nreasons - when running files or input over minutes\nSetting the latency parameter to 0, i.e. a buffersize indicated as 0, such\nthat the underlying sound engine will define its own size,\ngives dropouts, app 24 msec in about 15 seconds.\n\nMy suggestion is to experiment a little with the latency parameter, and if\nneeded I can create a version with a smaller\nincrement in buffersize for higher latency values (one issue on my laptop\nis that the default setting for all kinds of Latency\nin the portaudio module that I am using is 0 in all cases, so I \"invented\"\nmy own buffersize).\n\nbest\njan\n\n\n2017-02-15 14:23 GMT+01:00 zygmund2000 \[email protected]\u003e:\n\n\u003e CPU load is low all time, this droputs are not related to CPU load, looks\n\u003e like audio speed don't match to soundcard speed or something like this,\n\u003e because sound don't stop but change time.\n\u003e\n\u003e —\n\u003e You are receiving this because you commented.\n\u003e Reply to this email directly, view it on GitHub\n\u003e \u003chttps://github.com/JvanKatwijk/qt-dab/issues/10#issuecomment-280009382\u003e,\n\u003e or mute the thread\n\u003e \u003chttps://github.com/notifications/unsubscribe-auth/AITzwC5lzpCEt74X2s6Yl-pIwrcZzq3Iks5rcvxhgaJpZM4L-lhx\u003e\n\u003e .\n\u003e\n\n\n\n-- \nJan van Katwijk\n\n\n+31 (0)15 3698980\n+31 (0) 628260355\n"}],"action":{"name":"View Issue","url":"#10 (comment)"}}}
|
|
Yes, with this parameter the dropouts are more, less or even gone (for some seconds), depending on the entry. I'm alway replaying the same sdr-file, so I know when the dropouts appear. When dropouts occur, there is sometimes this message in the command window:
The SDR-J had
qt-dab has
Even when I move the mouse or the mouse scroll bar (when I was editing that page) I could produce dropouts ... CPU load depends on the latency parameter is between 40% and 55% |
|
Suggested size for outputbuffer =5120 is better, maybe skpis are too short to hear, I have
hardware calibrated rtlsdr and data speed shoud be very exact,
soundcard is also quite exact, dab signal is very very exact
at the moment. No console errors.
|
|
Two changes/additions
a. the granularity for the pcm buffersize is made smaller, now the size =
latency * 5 * 256, default value for latency parameter is 1.
b. a "secret" command line frag is added, -T. When selected, there will be
a continuous report on the amount of frameerrors and the amount of missed
samples.
hope this helps
jan
2017-02-16 23:48 GMT+01:00 andimik <[email protected]>:
… Yes, with this parameter the dropouts are more, less or even gone (for
some seconds), depending on the entry. I'm alway replaying the same
sdr-file, so I know when the dropouts appear.
When dropouts occur, there is sometimes this message in the command window:
ALSA lib pcm.c:7963:(snd_pcm_recover) underrun occurred
The SDR-J had
Suggested size for outputbuffer = 5120
qt-dab has
Suggested size for outputbuffer = 15360
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#10 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AITzwOKxQITKwcPgEYCUsTrzuiSQw3OVks5rdNItgaJpZM4L-lhx>
.
--
Jan van Katwijk
+31 (0)15 3698980
+31 (0) 628260355
|
|
Suggested size for outputbuffer = 1280 we have now DAB+ |
|
and in the longer run?
2017-02-17 11:21 GMT+01:00 zygmund2000 <[email protected]>:
… Suggested size for outputbuffer = 1280
we have now DAB+
frameErrors = 0, missed samples for audio 44800
frameErrors = 0, missed samples for audio 640
frameErrors = 0, missed samples for audio 0
frameErrors = 0, missed samples for audio 0
frameErrors = 0, missed samples for audio 0
frameErrors = 0, missed samples for audio 0
frameErrors = 0, missed samples for audio 0
frameErrors = 0, missed samples for audio 640
frameErrors = 0, missed samples for audio 0
frameErrors = 0, missed samples for audio 0
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#10 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AITzwBDUmSf02i3n4NcuEqy8sRdvbTzWks5rdXS7gaJpZM4L-lhx>
.
--
Jan van Katwijk
+31 (0)15 3698980
+31 (0) 628260355
|
|
I'll make the size of the granules 128.
j
2017-02-17 11:37 GMT+01:00 jan van katwijk <[email protected]>:
… and in the longer run?
2017-02-17 11:21 GMT+01:00 zygmund2000 ***@***.***>:
> Suggested size for outputbuffer = 1280
>
> we have now DAB+
> frameErrors = 0, missed samples for audio 44800
> frameErrors = 0, missed samples for audio 640
> frameErrors = 0, missed samples for audio 0
> frameErrors = 0, missed samples for audio 0
> frameErrors = 0, missed samples for audio 0
> frameErrors = 0, missed samples for audio 0
> frameErrors = 0, missed samples for audio 0
> frameErrors = 0, missed samples for audio 640
> frameErrors = 0, missed samples for audio 0
> frameErrors = 0, missed samples for audio 0
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#10 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AITzwBDUmSf02i3n4NcuEqy8sRdvbTzWks5rdXS7gaJpZM4L-lhx>
> .
>
--
Jan van Katwijk
+31 (0)15 3698980 <+31%2015%20369%208980>
+31 (0) 628260355 <+31%206%2028260355>
--
Jan van Katwijk
+31 (0)15 3698980
+31 (0) 628260355
|
|
... and you can always try "latency=0", then the portaudio layer looks for
a default size
j
2017-02-17 11:38 GMT+01:00 jan van katwijk <[email protected]>:
… I'll make the size of the granules 128.
j
2017-02-17 11:37 GMT+01:00 jan van katwijk ***@***.***>:
> and in the longer run?
>
>
> 2017-02-17 11:21 GMT+01:00 zygmund2000 ***@***.***>:
>
>> Suggested size for outputbuffer = 1280
>>
>> we have now DAB+
>> frameErrors = 0, missed samples for audio 44800
>> frameErrors = 0, missed samples for audio 640
>> frameErrors = 0, missed samples for audio 0
>> frameErrors = 0, missed samples for audio 0
>> frameErrors = 0, missed samples for audio 0
>> frameErrors = 0, missed samples for audio 0
>> frameErrors = 0, missed samples for audio 0
>> frameErrors = 0, missed samples for audio 640
>> frameErrors = 0, missed samples for audio 0
>> frameErrors = 0, missed samples for audio 0
>>
>> —
>> You are receiving this because you commented.
>> Reply to this email directly, view it on GitHub
>> <#10 (comment)>,
>> or mute the thread
>> <https://github.com/notifications/unsubscribe-auth/AITzwBDUmSf02i3n4NcuEqy8sRdvbTzWks5rdXS7gaJpZM4L-lhx>
>> .
>>
>
>
>
> --
> Jan van Katwijk
>
>
> +31 (0)15 3698980 <+31%2015%20369%208980>
> +31 (0) 628260355 <+31%206%2028260355>
>
--
Jan van Katwijk
+31 (0)15 3698980 <+31%2015%20369%208980>
+31 (0) 628260355 <+31%206%2028260355>
--
Jan van Katwijk
+31 (0)15 3698980
+31 (0) 628260355
|
|
still no errors, I have pulseaudio 10 and 48khz default sample rate, now in non realtime mode for tests. |
|
Now the dropouts disappeared as long as I don't use the scroll wheel on my mouse ...
|
|
On my 'Rasberry Pi 2 Model B I also have problems with hearable dropouts I tried latency=0, latency=2, latency=4 and latency=8. In the "technical data" window a CPU usage between 45 and 55 (%?) is shown and the four bars at the bottom are all at 100%. Does anybody have some ideas how to solve this problem? |
|
It seems the dropouts disappeared with newer versions. But I will check again. |
|
I compiled the latest version (0.999) and still have mayn of dropouts :-/ (using a dabstick on my Raspberry Pi) @JvanKatwijk can you comment on the meaning of these numbers and on the indicator "MOT decoding" (shown in the technical details)? |
|
Do you have dropouts when you comment out things like spectrum,
technicaldata etc etc
wrt the numbers:
they mean what is sais, frameerrors is the number of detected errors in the
frames and missed samples is missed samples in the
stream of 48000 samples/second
The numbers are not to be taken too seriously, the caounters are not always
reset. The numbers are merely for me to aid me
in some special checking .
2017-05-21 19:11 GMT+02:00 HawkingJan <[email protected]>:
… I compiled the latest version (0.999) and still have mayn of dropouts :-/
(using a dabstick on my Raspberry Pi)
frameErrors = 3, missed samples for audio 0
frameErrors = 0, missed samples for audio 0
frameErrors = 0, missed samples for audio 5151
frameErrors = 5, missed samples for audio 390
frameErrors = 4, missed samples for audio 5286
frameErrors = 1830, missed samples for audio 6387344
frameErrors = 75, missed samples for audio 95910
@JvanKatwijk <https://github.com/jvankatwijk> can you comment on the
meaning of these numbers and on the indicator "MOT decoding" (shown in the
technical details)?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#10 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AITzwK1WfjFd7nnb2BVuqxI53AlkN6B6ks5r8HA6gaJpZM4L-lhx>
.
--
Jan van Katwijk
+31 (0)15 3698980
+31 (0) 628260355
|
|
Thanks for your quick reply. |
|
I now compiled the latest version and removed "spectrum" (but kept the other entries listed in my previous post, maybe you can comment on MOT_DATA and MSC_DATA_)? I'm still not sure about the numbers printed using the -T option. Is the following interpretation correct? frameErrors = 0, missed samples for audio 0 <-- everything OK |
|
Interpretation is correct. There are three tests on DAB+ frames. The DAB
frames themselves are built up from 5 subsequent segments,
the first test is whether there is a frame or not, then with an RS
algorithm there is error correction to up to 5 byte errors in a 120 byte
frame,
If there are more than 5 errors the frame is rejected.
The implementation of RS needs revision since occasionally it happens that,
while RS states that all errors were corrected, the subsequent CRC fails
(which obviously should not happen).
A DAB+ frame contains 120msec of encoded sound, so when a frame is missing,
you miss for 120 msec samples, which with a samplerate of 48000 is about
5500
The counting of the amount of errors is not correctly done, and the exact
values themselves are - at least for me - not very interesting.
A timer polls the values, since there is a delay in the output (output is
sent to a buffer and asynchrously read) it might happen that frame errors
!= 0 and missed samples == 0
There is no display of the amount of corrected errors.
2017-05-24 0:56 GMT+02:00 HawkingJan <[email protected]>:
… I now compiled the latest version and removed "spectrum" (but kept the
other entries listed in my previous post, maybe you can comment on MOT_DATA
and MSC_DATA_)?
I'm running my Pi as a headless device over ssh. I assume that the CPU
usage value shown in the technical details is in percent? Then I'm using
between 40-52%. Which latency value do you use/recommend?
I'm still not sure about the numbers printed using the -T option. Is the
following interpretation correct?
frameErrors = 0, missed samples for audio 0 <-- everything OK
frameErrors = 5, missed samples for audio 0 <-- there were errors in the
frame that could be corrected, audio signal should be OK.
frameErrors = 20, missed samples for audio 55564 <--- there were errors in
the frame that could be corrected but audio signal still has issues (why?)
frameErrors = 0, missed samples for audio 5757 <-- ???
CRC failure with dab+ frame 2 (3) <-- there were errors in the frame that
could not be corrected (this error happens rarely)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#10 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AITzwA3stNB2seztBnwfTOj11qG-t3S1ks5r82QkgaJpZM4L-lhx>
.
--
Jan van Katwijk
+31 (0)15 3698980
+31 (0) 628260355
|
|
Wrt storing the coarse offset: having run a number of tests with different
devices, it shows that the offset is not constant over the different
channels, i.e. for the channels we are receiving here, the sdrplay that I
run shows an offset -1 for channel 5B and 2 for channel 12C.
For the dabstick is varies between -11 for channel 11C and -12 for channel
12C
Setting the ppm offset for the dabstick such that the coarse offset = 0 is
better, in that case (ppm offset = 84) I found a coarse
offset 0 on channels 8A, 11C and 12 C (those are the channels that can be
received with the dabstick, for 5B I need a different antenna
although I can receive that without problems with sdrplay and airspy)
2017-05-24 8:55 GMT+02:00 jan van katwijk <[email protected]>:
… Interpretation is correct. There are three tests on DAB+ frames. The DAB
frames themselves are built up from 5 subsequent segments,
the first test is whether there is a frame or not, then with an RS
algorithm there is error correction to up to 5 byte errors in a 120 byte
frame,
If there are more than 5 errors the frame is rejected.
The implementation of RS needs revision since occasionally it happens
that, while RS states that all errors were corrected, the subsequent CRC
fails (which obviously should not happen).
A DAB+ frame contains 120msec of encoded sound, so when a frame is
missing, you miss for 120 msec samples, which with a samplerate of 48000 is
about 5500
The counting of the amount of errors is not correctly done, and the exact
values themselves are - at least for me - not very interesting.
A timer polls the values, since there is a delay in the output (output is
sent to a buffer and asynchrously read) it might happen that frame errors
!= 0 and missed samples == 0
There is no display of the amount of corrected errors.
2017-05-24 0:56 GMT+02:00 HawkingJan ***@***.***>:
> I now compiled the latest version and removed "spectrum" (but kept the
> other entries listed in my previous post, maybe you can comment on MOT_DATA
> and MSC_DATA_)?
> I'm running my Pi as a headless device over ssh. I assume that the CPU
> usage value shown in the technical details is in percent? Then I'm using
> between 40-52%. Which latency value do you use/recommend?
>
> I'm still not sure about the numbers printed using the -T option. Is the
> following interpretation correct?
>
> frameErrors = 0, missed samples for audio 0 <-- everything OK
> frameErrors = 5, missed samples for audio 0 <-- there were errors in the
> frame that could be corrected, audio signal should be OK.
> frameErrors = 20, missed samples for audio 55564 <--- there were errors
> in the frame that could be corrected but audio signal still has issues
> (why?)
> frameErrors = 0, missed samples for audio 5757 <-- ???
> CRC failure with dab+ frame 2 (3) <-- there were errors in the frame that
> could not be corrected (this error happens rarely)
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#10 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AITzwA3stNB2seztBnwfTOj11qG-t3S1ks5r82QkgaJpZM4L-lhx>
> .
>
--
Jan van Katwijk
+31 (0)15 3698980 <+31%2015%20369%208980>
+31 (0) 628260355 <+31%206%2028260355>
--
Jan van Katwijk
+31 (0)15 3698980
+31 (0) 628260355
|
Closed
![https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open](https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open){kind=link}
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It seems never versions produce drop-out after inserting the CPU meter.
The text was updated successfully, but these errors were encountered: