Current State of the Pyra

[Wally]

Hi all,

Creating this thread so we have an idea on where we are at with the Pyra software / hardware, please only comment if you have fixed something here or have an idea that might fix the issue OR have discovered something I have missed which then can be added by a member of staff

I will also be making a kanban board (Trello or something) where people can take on tasks and communicate with vendors etc, I will be likely also posting this on the kernel mailing list to gain some further traction.

There will also be a possible survey for those with Pyras to report on whether they have the same things (Will provide some tests etc for each user to run)


Pyra State of things:


Input:
- Keyboard
Seems to work well with no issues including backlight

- Nubs
Works well with no issues via funkeymonkey

Power:
Battery - Appears to show as hot a lot.
Charging - Will stop if battery is hot, very selective about ports and cables (Document)

USB Output
USB-A 2.0 Port 1 (Blue Port)
USB-A 2.0 Port 2 (Black Port)
USB-3 OTG

HDMI Output
- Display is not rotated correctly and will crash after login

Audio Input
- Microphone
Appears not to work, just static
Audio Output
- Jack
- Speakers
- Seems to be issues with volume wheel being on anywhere over half and causes crackling / distortion when bass comes through

Display
- Backlight
- Backlight seems to be fine
- LEDS - Work fine, although a little bright

GPU
- Hardware is working correctly, Graphics are rendering however no 3D due to SDL2 potentially having issues. All issues with GPU have been resolved with current kernel, next kernel seems to have issues booting it.

Communications:

- Cellular
- Seems to have intermittent power problems
- Seems to have issues registering a network at times / Signal Strength
- Wifi
- Doesn't appear to be any issues

- Bluetooth
- Works well
- Could have adjustable volume via Audio Wheel.

- GPS
- Works - /dev/tty
Storage:
SD 1 - Works fine
SD 2 - Works fine
eMMC - Works fine

Other:
- Rumble
- Accelerometer
- Gyro
- Temperature Sensor
- FM Radio
- I'm sure i'm missing some..


OS Related Issues:
Unable to cleanly restart
Random freezing within the OS

 

[Magic Sam]

Hi all

@Wally : thank you for creating this thread, nice initiative IMHO.

Is the survey out yet ? I definitely could run some tests on my Pyra if that can help to solve some issues.

Cheers, Magic Sam

 

[elw3]

μSD card is missing. Wont boot if one is inserted.

 

[levi]

Well yes, the μSD card will replace what the system looks at for it's eMMC storage. There was a plan to try and multiplex the switch between the two and make both mountable, but obviously that's still down the list of things to try out. So if you insert an μSD card without a proper OS on it, it won't boot.

 

[fritata]

There are indeed wifi issues as mentioned in MasterJulian's first impressions thread as well as my own. Please add that to the list. Basically, the wifi randomly cuts out. This is most noticable during youtube video playback and buffering. I have done some basic troubleshooting. For some reason my router (running ddwrt) claims the pyra is a "legacy" device. I noticed the kernel buffer/dmesg output mentions the wifi chip failing to load a config file. I found an accompanying mailing message convo between Nikolaus and the Letux Kernel guys basically saying this should be fine and the config is optional. Some googling into TI's wifi chip config files makes me want to investigate it further, but this is all I have for now.

 

[EvilDragon]

Hmm, what would be interesting is to test when that happens (using 2.4 or 5 GHz connections) and if dmesg reports anything when WiFi is cut.

Not sure what you can setup with the config file.
I've played 20 Minutes of a YouTube video (with my router sitting on a different floor, about 15m away) and it didn't lose connection.

The more we can pinpoint it down the easier it should be to find a fix.

 

[Eight Bit]

I just had my first instance of audio going berserk with noise. It is not the same as the over driven speakers, I have set the master to 40% in the alsamixer to prevent that from happening.
It's more something like a buffer overflow. it just started playing loud data noise after a couple of minutes of normal behaviour and the original audio could still (slightly) be heard in the background. The noise can be controlled with the volume wheel.
Closing the application that was playing audio stopped the noise 2 seconds later.

 

[levi]

Yes, also when playing Soul Calibur in his Reicast video, Matty seemed to experience some ahead of noise corruption. It seemed to me that when the volume level went to max it triggered a few ms of noise. Yes, it is controllable with the volume wheel which suggests it's bad data into the system before the mixer.

I'm not sure a buffer overflow would cause this noise, at least the way that term is used in the security community. There, a buffer overrun is allowing someone to write past the end of a buffer. If you do that with a audio buffer, it'll just write to the space immediately after the buffer which you won't hear. You may hear a click every time it gets to the end of the buffer, because the waveform intensity won't match the start of the next buffer because it's effectively been cropped, but I wouldn't expect that the be as high frequency or as loud as the white noise effect we get is.

When the noise latched on, matty was able to stop it temporarily by exiting the app the sound was playing in, but in the end he rebooted because the noise does seem kind of sticky and happens more often once it's happened once.

But yeah it's interesting that you can hear the original tune under the noise. I wonder if it's clipping so extremely that is sounds akin to white noise. That could happen if in some situations the sound data gets processed in an u16 number before being cast into a s16 number (unsigned 16 but numbers have range 0 to 65535, but signed have -32768 to 32767)

 

[elw3]

This actually sounds like a line in channel is mixed into it.
You may just have to turn the microphone off.
But i suspect stuff is routed wrong a tad more than that.

 

[matzesu]

I will try this this evening when I make the GTA 3 Video, maybe it’s just matter of make some stuff in alsamixer ..

 

[elvissteinjr]

You may just have to turn the microphone off.

Yeah no, that doesn't work. At least not in the sense of muting it in alsamixer.

 

[elw3]

That was just an easy explainable analogy, dont read me literally.

 

[Eight Bit]

alsamixer is a mess...
The rumble motor is in it too btw, it does work.

 

[matzesu]

Maybe the strange sound i heard when I made the video wasn’t an sound issue but the rumble motor?? This would be cool..

I made some changes in Alsa for my video about the absolutely non violent driving simulator GTA3 , I don’t know if they worked
The video is currently uploading..

 

[EvilDragon]

Yeah no, that doesn't work. At least not in the sense of muting it in alsamixer.

No, you need to poke the register directly to turn off the microphone stream. Muting it does not disable the stream.

 

[matzesu]

So i just type alsamixer in my terminal, pull the microphone dial down, and I can play whiteout audio issues ?
Have to test it this afternoon

 

[levi]

No, that's not what ED just said. In all likelihood you're going to have to echo 0 > /sys/... somewhere to disable the microphone register

 

[matzesu]

Seems like this is a bit more difficult than the stuff i can do myself.., hopefully somewhere in the future there is an Update for this issue..

 

[levi]

Not really, once we know the path to write to. It's just a command in the terminal like the one you already do to start alsamixer. The only tricky thing is to get the path exactly right because the odds are there are lots of register files in the specified location all with different numbers, unlike alsamixer where you can pretty much type 'alsam' then <TAB> to complete the line for you. Might be suitable for creating a little script with the right incantations in it so it's easier to run in future.

 

[cjam]

From what I've read, the audio playback problem is correlated with high volume. I'd look at identifying out of bounds conditions (volume, not buffer overflow) in the alsa mixer. In the worst case it is evidence of a hardware problem, which still could be avoided by identifying the software state that triggers it.

Is someone developing automated / scripted testing to trigger it, identify when it happens with different things toggled on and off?