(03-02-2021, 02:36 PM)as400 Wrote: Absolutely. These problems are known for more than a year. So now the situation looks like they are knowingly and deliberately sell product that is faulty by design.
Sad to say, but this is the way big corporations behave. They just don't react at all.
It is really sad that the Pine64 team simply ignores the issues and even announces the next PineBook Pro batch that will be made and shipped with a whole bunch of known issues. Really, really sad and totally unexpected from Pine64.  I understand that the effects of the current pandemic must be hard for Pine64, but getting involved into the discussions requires very little effort and no money.
(03-05-2021, 12:53 AM)esud Wrote: The benefit is that it is possible to charge the notebook from powerbank. It make sense when someone travel to forest or similar places where is no 220v AC electricity available.
And also possible to charge from USB-charger which can be used for another purposes (like to charge mobilephone,...). In classic notebooks which are working with 15-20volt we always need to take separate charger which can be used only with the given notebook modell. With USB we have universal solution.
This is a valid point, but 3 A at 5 V simply isn't enough juice for the PineBook Pro almost whenever it's doing something CPU-hungry. The right solution would be to improve the USB Type-C power input so it can take significantly more power from a capable USB Power Delivery charger, while also remaining compatible with the USB chargers capable of providing only 3 A at 5 V.
I've already researched that approach a lot, putting a lot of time into studying the PineBook Pro internals, and I've asked the Pine64 team twice to provide me with a development PineBook Pro, which I'd use to try out some hardware modifications that would raise the input power. Unfortunately, the Pine64 team remained completely silent.
(03-09-2021, 04:14 AM)dsimic Wrote: It is really sad that the Pine64 team simply ignores the issues and even announces the next PineBook Pro batch that will be made and shipped with a whole bunch of known issues. Really, really sad and totally unexpected from Pine64. I understand that the effects of the current pandemic must be hard for Pine64, but getting involved into the discussions requires very little effort and no money.
Somebody already wrote on this forum - there is a certain amount of "fanboyism" going on around here. So if you say "hey, this is an issue", you are going to get replies that if you buy laptop for 200 USD you can't expect it to be perfect.
Well, I don't agree with that completely. Design faults that are mentioned in this thread are absolutely fundamental.
And I can't also understand why having a person like yourself - wanting to help - they just refuse to use your help. I mean I probably know why, but I don't want get crucified here
But no worries - there are legions of ARM chromebooks that are coming to market this year. Some of them will have good Linux support. And will probably be faster and more capable than pbp by a mile.
Well, I clearly did not expect the first revision of a $200 ARM laptop to be perfect. However, I do expect the second revision of the same $200 ARM laptop to include the fixes for the hardware issues reported by the community consisting of its early adopters. That's simply how a product evolves and becomes better over time.
I am really puzzled about why the Pine64 team remains silent? I believe I speak for pretty much all contributors to this thread when I say this: We are by no means bashing the PineBook Pro; instead, we want to fix the issues, make the PineBook Pro better, and to see Pine64 selling it to a huge number of happy end-users and developers.
By the way, Apple's M1 SoC will surely cause a wave of changes. I'm not a fan or an user of Apple products, but I admit they do make good products. More importantly, the M1 clearly demonstrates that ARM SoCs can be much more than just a "toy", while the M1-based products set the bar for what people are willing to pay for an ARM device. That should make it possible for many more manufacturers to have enough headroom for making very good ARM devices.
03-15-2021, 11:41 AM
(This post was last modified: 03-16-2021, 08:31 AM by dsimic.)
(03-02-2021, 02:36 PM)as400 Wrote: (02-22-2021, 03:28 AM)dsimic Wrote: I would also add some weird crackling/popping noises coming out of the speakers while no music playback is active. I've been unable to correlate those sounds to anything else happening on the laptop, except for the moment of powering off the laptop, which always produces a crackle/pop.
Yes, I had this too.
It could be related to the reported crosstalk between the audio output and the serial console, but the linked description of the crosstalk issue reports garbage on the serial console only with maximum audio playback volume, while I hear weird crackling/popping noises with no audio playback at all.
For the sake of completeness, here's a quotation from the above-linked web page:
Quote:Selectable by a hardware switch, the audio jack can be either used for audio or serial console. A Manjaro developer pointed out a third hardware bug namely crosstalk between the audio and serial line, e.g. when cranking up audio to distortion characters are sent to the console:
# systemctl stop serial-getty@ttyS2
# hexdump -C /dev/ttyS2
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 |................|
00000010 00 00 00 00 00 00 00 00 80 00 00 00 00 00 01 00 |................|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 f0 00 00 |................|
00000040 00 00 00 00 00 00 00 00 51 00 00 00 00 00 ff 00 |........Q.......|
00000050 00 00 ff 00 fe 00 00 00 e0 00 00 00 00 00 00 00 |................|
00000060 00 00 01 00 00 00 00 80 00 00 00 00 00 00 00 00 |................|
00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
When not disabled in the kernel, these characters are interpreted by the kernel as MAGIC SYSRQs and bring down the kernel every now and then.
Edit: Nope, these two issues are not correlated. After spending some more time on debugging and researching, I'm positive that I've located the actual source of the crackling/popping noises.  More details will be available in my next post.
Randomly appearing crackling/popping noises are definitely created by the audio hardware getting suspended whenever it becomes idle for a certain amount of time. Actually, it is the PulseAudio module named " module-suspend-on-idle" that suspends idle audio hardware.
An easy way to reproduce a crackling/popping noise is to open a YouTube video in Firefox and close the browser tab after a few seconds of audio/video playback. After a few seconds, there comes the dreaded crackling/popping noise, as a result of the audio hardware becoming idle and, consequently, suspended.
I had no luck with disabling the aforementioned module in the PulseAudio configuration, which should mitigate the issue. The downside would be increased power consumption. However, for some reason, disabling the module caused either no sound at all, or caused loud hissing all the time. I haven't debugged that further.
Alright, the logical next step is to create a proof of the entire "keep it busy" concept, effectively subverting the aforementioned PulseAudio module. So, let's whip up something simple to keep the audio hardware active all the time; this does the trick:
Code: aplay -r 8000 -f S16_LE /dev/zero
With this running in the background, I'm yet to hear a single crackling/popping noise, despite trying actively to reproduce the issue. Woohoo!
Surely, this is just a dirty workaround, but it clearly proves that the source of the issue is now properly located. The actual underlining issue is probably an incorrect order in which various components of the entire audio subsystem are powered on and off in the Linux kernel driver. This document provides further information.
I'll probably research this further, aiming at the right solution.
03-16-2021, 10:02 AM
(This post was last modified: 03-16-2021, 10:07 AM by pixelherodev.)
Another solution to the audio issue is to script ALSA to disable the speaker control. Or to reduce Boost to 0. Or...
Using ALSA instead of Pulse is much more pleasant on the PBP. Pulse has way too many bugs with it; ALSA works flawlessly for me.
Edit: oh, and the power consumption of the codec is 7mW at its worst (for playback-only). There's no real reason to care to suspend it. If you have a battery life of 13 hours, you have an average consumption of ~3077mW. This change cost you roughly 80 seconds of battery life, tops.
03-16-2021, 02:44 PM
(This post was last modified: 03-19-2021, 03:45 AM by dsimic.
Edit Reason: Fixed a link and clarified a bit
)
What boost setting are you referring to? I have no such option (i.e. control element) in alsamixer.
I'm not sure about ever been able to reach even close to 10 hours of battery life? However, you're right about the low playback-only consumption of the ES8316 codec ( datasheet), but the additional consumption of two speaker amplifiers ( XA9108) should be accounted as well. Unfortunately, I've been unable to find the datasheet for the XA9108 amplifier.
Until a better solution is available, increasing the total power draw of the laptop by about 7 to 15 mW is IMHO a very good trade-off for not having those annoying crackling/popping noises.
I've recently noticed that the screen on my PineBook Pro sometimes flickers a couple of times when I plug a USB 3.0 device (a Gigabit Ethernet dongle, to be precise) into the USB 3.0 port next to the barrel port for the charger. It's like the screen backlight or the entire screen quickly turns off and back on a couple of times. The screen continues to work just fine afterwards, as if nothing happened.
Upon further investigation, it seems that getting the USB 3.0 plug to lightly touch the USB 3.0 socket, so the internals of the plug touch the internals of the socket but without starting the actual mating of the connectors, triggers this issue. The even more weird part is that it does not happen always, but when it happens, I can easily use the described way to make the screen flicker a few times in a row.
Has anyone else encountered this?
(05-09-2021, 01:29 AM)dsimic Wrote: I've recently noticed that the screen on my PineBook Pro sometimes flickers a couple of times when I plug a USB 3.0 device (a Gigabit Ethernet dongle, to be precise) into the USB 3.0 port next to the barrel port for the charger. It's like the screen backlight or the entire screen quickly turns off and back on a couple of times. The screen continues to work just fine afterwards, as if nothing happened.
Upon further investigation, it seems that getting the USB 3.0 plug to lightly touch the USB 3.0 socket, so the internals of the plug touch the internals of the socket but without starting the actual mating of the connectors, triggers this issue. The even more weird part is that it does not happen always, but when it happens, I can easily use the described way to make the screen flicker a few times in a row.
Has anyone else encountered this?
Could be a ground loop.
|
