USB data loss and ALSA problems

Bringing in some text from the other thread to make this one self-contained ...

The way I'm testing the loss of mouse clicks is simply by putting two xterm windows side by side and left-clicking them alternately while the music is playing, and counting the clicks.  If a click is missed then the window doesn't gain focus and that's immediately visible.  So far I always get a missed click before reaching a count of 30.  The average interval between lost clicks is much less though, maybe around 12-15 clicks, and sometimes two clicks are lost in succession.

Also, the keyboard sometimes goes into autorepeat on pressing a character, which suggests that the key release event is being lost and hence autorepeat gets activated.

And I'm not sure if this is related or not, but sometimes I type a whole commandline in without looking, hit return, and see nothing typed on the xterm at all ... then a few seconds later it appears, along with the command output.  That's pretty bizarre, becaused the characters typed should be displayed by interrupt routines and have nothing to do with user process scheduling, on normal machines at least.

So you're seeing loss of mouse clicks.  What about mouse movement?  There's a lot more mouse data from movement than from clicks.

Usually, X11 programs combine queued up mouse movement events to reduce mouse lag if X11 gets slow.  They don't usually combine queued up button clicks since every one of those matters.

I haven't seen any mouse or keyboard misbehavior personally, but I haven't spent that much time with my RasPi.  I have the joy of a young kitten on the physical desktop and she loves playing with cables.  For me, repeated keystrokes are generally kitten-related.

I haven't noticed the pointer freezing at all.  I assume that this is because pointer movement events occur at such a fast rate with these modern high-resolution mice that even if one or a few motion events are lost, it's just not noticeable because subsequent ones make up for it.

I have encountered issues too..

When playing MP3s with MPG321 using "amixer" to control the volume will  sometimes cause the ALSA to hang. using either Ctrl+C or running amixer again can start the music playing again.

It seems to me to be flakeyness in the driver - maybe a lost interrupt or something. It is a pretty reliable test to cause a hang - maybe one in 5 times when running amixer....

Not wanting to try to teach you how to suck eggs, but...

You have tried:

power through gpio header from a decent bench psu ?

all usb stuff on an externally powered USB hub ?

bridging polyfuses and/or running a pi-pass ?

larger cap across usb power ?

wired, not wireless keyboard/mouse ?

different kernels ?

cut-down install - something that doesn't have 101 unnecessary daemons running ?  (my feeling here is that the Pi likely isn't suited to a full-blown desktop distro that was designed with a quad core 3Ghz x86_64 and 16Gb of Ram in mind)

I have occasionally seen the repeating key problem, but it's not been something I can reliably reproduce and as such impossible to get a handle on what's causing it.

selsinork:  I haven't tried most of those because I don't see a causal path that would connect them with the problem.  Pi power is a bit ropey, sure, but my TP1 is at 4.89V and the only USB port that is being used is for the Logitech receiver which is taking less than 3mA and hence running totally cold.  That doesn't make me suspect power issues in the first instance, although noise on the power line still needs to be eliminated.

I haven't tried wired keyboard and mouse yet because mine are mostly old and power-hungry (which is why I bought the modern Logitech with the combined receiver).  It's a good thing to try though, because EMC problems might be the culprit.  I have one similar test lined up, which is to put the Logitech receiver on a long USB lead so that its RF near-field can't affect the Pi nor vice versa.

I haven't tried any new drivers or kernels or blobs yet, and I'll have to migrate to a bigger SD card before I can rebuild the kernel as I'm right up against the ceiling currently.  Is there anything that isn't in the recommended Debian image which might improve matters?

The 300Hz mod sounds like a disaster, but I guess I should try it just in case.

Morgaine.

Power issues are a tricky one. Too many reports of problems that go away with a better PSU or micro usb cable to rule them out without trying it. Also TP1 voltage isn't necessarily the whole story, have seen several reports of the polyfuses between TP1 and the usb ports having oddly high resistances, so test voltage on the usb port itself rather than TP1.  No way 3mA should be a problem, but for the sake of a couple of minutes what do you have to lose ?

Others have had luck with either replacing the polyfuses with a wire link or bypassing the whole thing with a heavy wire direct from micro usb to the usb ports - although this seems to leave the bottom usb port unuseable..

Obviously YMMV with any of the power mods as it'll depend a lot on your Pi and whatever devices you plug into it.. In my case it was the micro-usb power cables that were the biggest problem 0.5v+ drop across the cable regardless of the actual power source.

I don't believe there's anything missing from the Debian image, newer kernel/blob just rules out an existing bug that may have been fixed.

Compiling the kernel on the Pi is slow, around 3-4 hours for me with the kernel source on NFS and that's with most of the junk stripped out.  If you have another linux machine available I'd recommend using crosstool-ng to build a cross compiler and reduce the time.

selsinork wrote:

 

No way 3mA should be a problem, but for the sake of a couple of minutes what do you have to lose ?

Agreed.

I did  test F1 and F2 even before I had USB power available --- http://www.element14.com/community/message/54970#54970 --- but wierd things do happen, and you can't measure too often.

Others have had luck with either replacing the polyfuses with a wire link or bypassing the whole thing with a heavy wire direct from micro usb to the usb ports - although this seems to leave the bottom usb port unuseable.

I won't be doing any hardware hacking until Pi boards are ex-stock.  This ordering and waiting process isn't for me, and I only put up with it once.

Morgaine what image are you working with ?

I experienced some network issues with Debian (not the beta), and running a quick test sending a ping flood test from another unix machine, the R-pi gives a kernel panic after few minutes, sometimes even less than a minute.

I didn't track it down in the kernel, but it looked like there is some issue with the USB driver and interrrupt management.

I was not able to replicate the problem with the Debian Wheezy beta or with Arch Linux

My .02

-J

Just standard Squeeze debian6-19-04-2012.zip that's on their download page here, augmented with a few tools for testing, no major changes as I don't want to introduce new variables at this stage.

I also installed IceWM to check it works on ARM because I'll be using it later by preference.  Interestingly, I see it has signficantly less overhead than OpenBox, so players start up cleaner than with the standard desktop (no ALSA grating during buffer preload).  But during tests I'm still using OpenBox, because that's the reference.

Another interesting observation:  the MOC player's CPU usage of around 30% when playing my Oggs drops to 7% when playing mp3 files, so a tentative guess is that MP3 is decoded by the SoC and Ogg is not.  mpg123 has the same CPU usage as MOC on MP3 files, but of course can't handle Ogg.

Using the Pi over ssh from various boxes overcomes the mouse click loss, and is significantly more responsive as the Pi's sluggish CPU doesn't matter then.

I also installed Synergy on Pi, which gives me yet another way of avoiding the USB mouse problems.  I use Synergy quite a lot at home anyway to avoid keyboard/mouse proliferation, and it'll be the preferred way of using Model A without needing a powered hub, just dedicating the single USB to a wifi dongle.

Morgaine.