Re: XOs with no sound
Alsa keeps the values in memory and writes it into the /etc/alsa/asound.state file during shutdown. The file has a new timestamp, so someone is writing into it at least. Sorry my master asound.state file was working but not standard. I have now 5 values that are different between a standard XO (build 767) and a no sound XO Master Mono Playback Switch: is false should be true (line 50) Master Mono Playback Volume: is 0 should be 28 (line 61) PCM Playback Switch: is false:false should be true:true (line 178) PCM Playback Volume: is 0:0 should be 22:22 (line 190) Capture Volume: is 0:0 should be 15:15 (line 287) I hope that helps. Regards, Philipp James Cameron wrote: On Wed, Dec 31, 2008 at 09:22:17AM +0700, Philipp Kocher wrote: It seems like always the same 7 values are wrong. Which 7 values? 1. Copy /etc/alsa/asound.state of a healthy XO to USB flash drive Okay, so it is in /etc/alsa on those builds? Are you sure that file is in use? On the build I'm using, there is a file in /etc/alsa/asound.state that is not updated, as well as one in /etc/asound.state . (I would have thought /var would have been more appropriate). Your process has two steps and requires a working XO. I think it is even simpler to alsactl -f /dev/null restore ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XOs with no sound
On Wed, Dec 31, 2008 at 03:52:05PM +0700, Philipp Kocher wrote: Alsa keeps the values in memory and writes it into the /etc/alsa/asound.state file during shutdown. The file has a new timestamp, so someone is writing into it at least. Okay, that must be a build 767 thing. Recent development builds use /etc/asound.state only. I've checked only the development builds at this stage. Master Mono Playback Switch: is false should be true (line 50) Master Mono Playback Volume: is 0 should be 28 (line 61) These two should have no effect. I've tested that they have no effect on audio playback. The method I used was to temporarily install the OSS module, and run a background process writing noise to the output. Thus: modprobe snd-pcm-oss dd if=/dev/urandom of=/dev/dsp While this is running I then manipulated the controls using alsamixer. The Master Mono Playback controls did nothing. (Incidentally, the volume control keys on the keyboard changed the Master control only, not the Master Mono control, and not the PCM control.) PCM Playback Switch: is false:false should be true:true (line 178) In false:false state, this switch prevents all sound output from activities and applications. The noise test above fell silent. PCM Playback Volume: is 0:0 should be 22:22 (line 190) In 0:0 state, the audio is less loud, but not eliminated. The noise test continued to generate audio, but I needed to set the Master control (not the Master Mono control) to at least 50%. Capture Volume: is 0:0 should be 15:15 (line 287) In this state, the noise test audio is unchanged. This would affect sound capture using microphone though. I hope that helps. Yes, it does. It shows the immediate cause of the problem was that the PCM Playback Switch was turned off. That the Capture control was also changed is interesting. I've searched the installed activities on a development build here for references to the amixer command. The only activity that I've found it used in is Measure. Measure.activity/toolbar_side.py ... changes the Capture control. Measure.activity/audiograb.py ... changes the PCM Playback Switch. Is Measure being used? Can you reproduce the symptom on a working XO by asking for a shutdown while Measure is running? What version of Measure is being used? Version 20 of Measure attempts to restore PCM to 70 on quit. Does the symptom clear if Measure is started and then quit? -- James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: performance work
On Tue, 2008-12-30 at 20:41 -0700, Jordan Crouse wrote: I'm curious as to why reads from video memory are so slow, On standard video cards it's slow because there is quite a division between the CPU and the video memory, but on the geode isn't the video memory shared in the same SDRAM as Main memory. It is, in that they share the same physical RAM chips, but they are controlled by different entities - one is managed by the system memory controller and the other is handled by the GPU. At start up time, the memory is carved up by the firmware, and after the top of system RAM is established, video and system memory behave for all intents and purposes like separate components. Put simply, there is no way to directly address video memory from the system memory. Access to the video memory has to happen via PCI cycles, and for obvious reasons the active video region has the cache disabled, accounting for relatively slow readback. That makes my brain melt, you can't address it even though it's on the same chip!?! Even as far back as the PCjr the deal was that sharing video memory cost some performance due to taking turns with cycles but it gave some back with easy access to the memory for all. Has the geode cunningly managed to provide a system that combines all the disadvantages of separate memory with all the disadvantages of shared? One wonders what would happen if you wired some lines to the chips so that the memory appeared in two places, would you get access to the ram (with the usual 'you pays your money, you takes your chances' caveats about coherency) I'm not a hardware person, but that all just seems odd. That said, the read from memory performance is still worse then you might expect - I never really got a good answer from the silicon guys as to why. being hit with the full sdram latency every access maybe? Is it feasible to try with caches enabled and require the software to flush as needed. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: performance work
Neil Graham wrote: On Tue, 2008-12-30 at 20:41 -0700, Jordan Crouse wrote: I'm curious as to why reads from video memory are so slow, On standard video cards it's slow because there is quite a division between the CPU and the video memory, but on the geode isn't the video memory shared in the same SDRAM as Main memory. It is, in that they share the same physical RAM chips, but they are controlled by different entities - one is managed by the system memory controller and the other is handled by the GPU. At start up time, the memory is carved up by the firmware, and after the top of system RAM is established, video and system memory behave for all intents and purposes like separate components. Put simply, there is no way to directly address video memory from the system memory. Access to the video memory has to happen via PCI cycles, and for obvious reasons the active video region has the cache disabled, accounting for relatively slow readback. That makes my brain melt, you can't address it even though it's on the same chip!?! Even as far back as the PCjr the deal was that sharing video memory cost some performance due to taking turns with cycles but it gave some back with easy access to the memory for all. Has the geode cunningly managed to provide a system that combines all the disadvantages of separate memory with all the disadvantages of shared? One wonders what would happen if you wired some lines to the chips so that the memory appeared in two places, would you get access to the ram (with the usual 'you pays your money, you takes your chances' caveats about coherency) I'm not a hardware person, but that all just seems odd. You are missing the point - this model wasn't designed so that the system could somehow sneakily address video memory, it was designed so that the system designer could eliminate the need for the added cost, expense and real estate for a separate bank of memory chips. See also http://en.wikipedia.org/wiki/Shared_Memory_Architecture. That said, the read from memory performance is still worse then you might expect - I never really got a good answer from the silicon guys as to why. being hit with the full sdram latency every access maybe? Is it feasible to try with caches enabled and require the software to flush as needed. Ask around - I don't think that you'll find anybody too keen on having the X server execute a cache invalidate a half dozen times a second. Anyway, you are getting distracted and solving the wrong problem. You should be more concerned about limiting the number of times that the X server reads from video memory rather then worrying about how fast the read is. If I can rant for a second (and this isn't targeted at Neil specifically, but just in general), but this is another in a list of more or less hard constraints that the current XO design has. Throughout the history of the project, it seems to me that developers have been more biased toward trying to eliminate those constraints rather then making the software work in spite of them. The processor is too slow - everybody immediately wants to overclock. There is too little memory - enter a few dozen schemes for compressing it or swaping it. The XO platform has limitations, most of which were introduced by choice for power or cost reasons. The limitations are clearly documented and were known by all, at least when the project started. The understanding was that the software would have to be adjusted to fit the hardware, not the other way around. Over time, we seem to have lost that understanding. Software engineering is hard - software engineering for resource restrained systems is even harder. In this day and age geeks like us have been accustomed to always having the latest and greatest hardware at our fingertips, and so the software that we write is also for the latest and greatest. And so, when confronted with a system such as the XO, our first instinct is to just plop our software on it and watch it go. That attitude is further re-enforced by the fact that the Geode is x86 based - just like our desktops. It should just work, right? We know better - or at least, we should know better. The solution to the performance problems is good old fashioned elbow grease. We have to take our software that is naturally biased toward the year 2007 and make it work for the year 1995. Thats going to involve fixing bugs in the drivers, but also re-thinking how the software works - and finding situations where the software might be inadvertently doing the wrong thing. Let me give you an example - as recently as X 1.5, operations involving an a8 alpha mask worked like this: * Draw a 1x1 rectangle in video memory containing the source color for the operation * Read the source color from video memory * Perform the mask operation with the source color This isn't smart for any kind of processor or GPU, running at 2 Ghz or
1cc network outage
We had an interruption in network services at 1cc from about 10:30 am to 11:15 am this morning. This affected the reverse proxy server serving the wiki as well as phone and network services at 1cc. --HH. -- We've heard that a million monkeys at a million keyboards could produce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true. -- Robert Wilensky, 1996 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
9.1.0 meeting - 2PM US ET Today 12/31
Hi All, I'll be on IRC freenode.net #olpc-meeting at 2PM US ET today. Minutes of last weeks meeting and this weeks agenda are here: http://lists.laptop.org/pipermail/devel/2008-December/022085.html We can table the agenda and call it a year unless there are updates or other comments. Happy New Year everyone. We are a phenomenal engineering team and community network of experts in every aspect of life and learning. What a great year! Let's do it again next year. Thanks, Greg S ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: performance work
On Wed, Dec 31, 2008 at 09:20:27AM -0700, Jordan Crouse wrote: The solution to the performance problems is good old fashioned elbow grease These are the sorts of things that we need to find and squash - and yes, it will be very time consuming and a little boring. Several anecdotes for your amusement and reflection: * When was the last time someone posted to devel asking: what is the right algorithm or datastructure for task ? * When was the last time someone publicly analyzed the upper or lower bounds on the bandwidth, latency, or quantity of messages necessary to accomplish task ? * When was the last time that you published a performance goal for your software? Did you hit it? Did anyone notice? Michael P.S. - Charles Leiserson once remarked that performance is like a currency which programmers trade for (all) other worthwhile things like schedule targets, scope of features, other resource consumption, various kinds of security, etc [1]. This suggests that one would do better to ask for performance or but not both. Think of Blizzard. [1] http://www.catonmat.net/blog/mit-introduction-to-algorithms-part-one/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: performance work
I agree with Jordan. You just have to sit down and do the work to optimize the code, either finding the fastest path through hardware and software stack. I've rewritten Bounce twice now for performance just to hold on to 20fps on the XO. Colors! has been through many performance iterations as well (compare v1 and v13 with large brushes). I've just had my hat handed to me by Cairo for Typing Turtle as well (with the hand display enabled, you can type about 1WPM). So I'm looking forward to rewriting my keyboard rendering to deal with that. If you have an issue with the performance of the XO, just spend the time by yourself to analyze it and fix it, talking about it accomplishes nothing. If you find a solution that would help others, post it. -Wade ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: performance work
Hi All, Answering two e-mails on one pass. I agree, its hard work. Wade, I believe this thread is about optimizing the XO OS and GUI. That's why I call the requirement General_UI_sluggishness. Optimizing applications is yet another challenge. I'm all for people doing that hard work and documenting it so the next person doesn't have to re-invent the wheel. Your performance URL is already posted to the page in the tools section. Let me know if you have any other links (GIT URLs?) or e-mails I should make easily accessible. Michael, The performance goal I worked out with Eben is on the page already. It could be better but its a start. Lots of people have noticed. Neil and Jordan analyzed which Cairo calls are causing the most trouble and how long they take. I also broke John's suggestions in to general areas: http://wiki.laptop.org/go/Feature_roadmap/General_UI_sluggishness Could use more editing (e.g. swap suggestions may belong in memory, file read/write caching should be added etc.). You're just scratcing the surface with BW, latency and messages. CPU cycles, process priority, caching, bottleneck definition, instruction sets and compilers, word/block/sector size usage, and if you're really hard core rows and columns are all optimizable. If you have an algorithm improvement to offer, I'm all ears. When we have a critical mass of time from professional engineers we can improve performance. Until then it waits and the users wait too. Let's build on what we have, we're making progress. Thanks, Greg S On Wed, Dec 31, 2008 at 09:20:27AM -0700, Jordan Crouse wrote: The solution to the performance problems is good old fashioned elbow grease These are the sorts of things that we need to find and squash - and yes, it will be very time consuming and a little boring. Several anecdotes for your amusement and reflection: * When was the last time someone posted to devel asking: what is the right algorithm or datastructure for task ? * When was the last time someone publicly analyzed the upper or lower bounds on the bandwidth, latency, or quantity of messages necessary to accomplish task ? * When was the last time that you published a performance goal for your software? Did you hit it? Did anyone notice? Michael P.S. - Charles Leiserson once remarked that performance is like a currency which programmers trade for (all) other worthwhile things like schedule targets, scope of features, other resource consumption, various kinds of security, etc [1]. This suggests that one would do better to ask for performance or but not both. Think of Blizzard. [1] http://www.catonmat.net/blog/mit-introduction-to-algorithms-part-one/ Wade Brainerd wrote: I agree with Jordan. You just have to sit down and do the work to optimize the code, either finding the fastest path through hardware and software stack. I've rewritten Bounce twice now for performance just to hold on to 20fps on the XO. Colors! has been through many performance iterations as well (compare v1 and v13 with large brushes). I've just had my hat handed to me by Cairo for Typing Turtle as well (with the hand display enabled, you can type about 1WPM). So I'm looking forward to rewriting my keyboard rendering to deal with that. If you have an issue with the performance of the XO, just spend the time by yourself to analyze it and fix it, talking about it accomplishes nothing. If you find a solution that would help others, post it. -Wade ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: performance work
Hi Greg, I think there's actually a lot of overlap between activity performance work and OS performance work. The bottlenecks I encountered and resolved were in PyGTK, Cairo, the Python interpreter, librsvg, etc. These are the many of the same libraries which are believed to cause sluggishness in the core UI. Unfortunately, most of my performance success was had by replacing the aforementioned libraries with custom C++ extension modules. Each time I remove some Cairo code and replace it with custom C++ code, the activity gets faster. I wouldn't advocate the Sugar developers take that approach :) -Wade On Wed, Dec 31, 2008 at 4:01 PM, Greg Smith gregsmitho...@gmail.com wrote: Hi All, Answering two e-mails on one pass. I agree, its hard work. Wade, I believe this thread is about optimizing the XO OS and GUI. That's why I call the requirement General_UI_sluggishness. Optimizing applications is yet another challenge. I'm all for people doing that hard work and documenting it so the next person doesn't have to re-invent the wheel. Your performance URL is already posted to the page in the tools section. Let me know if you have any other links (GIT URLs?) or e-mails I should make easily accessible. Michael, The performance goal I worked out with Eben is on the page already. It could be better but its a start. Lots of people have noticed. Neil and Jordan analyzed which Cairo calls are causing the most trouble and how long they take. I also broke John's suggestions in to general areas: http://wiki.laptop.org/go/Feature_roadmap/General_UI_sluggishness Could use more editing (e.g. swap suggestions may belong in memory, file read/write caching should be added etc.). You're just scratcing the surface with BW, latency and messages. CPU cycles, process priority, caching, bottleneck definition, instruction sets and compilers, word/block/sector size usage, and if you're really hard core rows and columns are all optimizable. If you have an algorithm improvement to offer, I'm all ears. When we have a critical mass of time from professional engineers we can improve performance. Until then it waits and the users wait too. Let's build on what we have, we're making progress. Thanks, Greg S On Wed, Dec 31, 2008 at 09:20:27AM -0700, Jordan Crouse wrote: The solution to the performance problems is good old fashioned elbow grease These are the sorts of things that we need to find and squash - and yes, it will be very time consuming and a little boring. Several anecdotes for your amusement and reflection: * When was the last time someone posted to devel asking: what is the right algorithm or datastructure for task ? * When was the last time someone publicly analyzed the upper or lower bounds on the bandwidth, latency, or quantity of messages necessary to accomplish task ? * When was the last time that you published a performance goal for your software? Did you hit it? Did anyone notice? Michael P.S. - Charles Leiserson once remarked that performance is like a currency which programmers trade for (all) other worthwhile things like schedule targets, scope of features, other resource consumption, various kinds of security, etc [1]. This suggests that one would do better to ask for performance or but not both. Think of Blizzard. [1] http://www.catonmat.net/blog/mit-introduction-to-algorithms-part-one/ Wade Brainerd wrote: I agree with Jordan. You just have to sit down and do the work to optimize the code, either finding the fastest path through hardware and software stack. I've rewritten Bounce twice now for performance just to hold on to 20fps on the XO. Colors! has been through many performance iterations as well (compare v1 and v13 with large brushes). I've just had my hat handed to me by Cairo for Typing Turtle as well (with the hand display enabled, you can type about 1WPM). So I'm looking forward to rewriting my keyboard rendering to deal with that. If you have an issue with the performance of the XO, just spend the time by yourself to analyze it and fix it, talking about it accomplishes nothing. If you find a solution that would help others, post it. -Wade ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: performance work
What I find discouraging is mentally comparing the responsiveness in use of F10-based Joyride builds against what I remember (perhaps mistakenly) of responsiveness with Ship.2 builds. [I don't currently have a Ship.2 system on hand for direct comparison.] Examples of my (non-performance) experience with recent Joyrides : - I use an external USB keyboard. In Terminal, I type in a short command and press enter. It can take more than half a second (or even longer) for the cursor to move from the line it was on (where I typed) to the start of a new screen line. - I click on an Activity icon in Home View or Journal. Up to TWO seconds later, the XO begins showing (and pulsing) the screen that is supposed to indicate Activity being launched. [The only way I can get 'instant' response from the XO is to elicit the drop-down palette from the Activity icon, then click in that palette on Start (if in Home View) or on Resume (if in Journal). Having done so, the vanishing of that palette is satisfyingly responsive. (Of course, if I were to miss the palette entirely due to my shaky hands when I click, the palette vanishes without the Activity being launched.)] mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Installing Flash on the OLPC
Dear =S Page, As the social analog of town drunk on this list, I am flattered as hell to be lumped in with the smart set! ¡Gracias! genesee S Page-2 wrote: you're just making the smart smarter still. -- View this message in context: http://n2.nabble.com/Installing-Flash-on-the-OLPC-tp2088845p2098061.html Sent from the Software development mailing list archive at Nabble.com. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Flash wiki entries
gently Many more people are going to read http://wiki.laptop.org/go/Adobe_Flash page than follow this mailing list. Your effect on XO users by only answering problems here is limited, you're just making the smart smarter still. Just in time for New Year's resolutions: edit the wiki page first. Hey Skier! Your wish is my command :) Just did a massive update to the Adobe Flash page, hope to update the main Flash Player and Gnash pages as well soon, pending spare time off work. I hope this doesn't offend anyone, but I de-emphasized Webkinz.com with the newer edits because the old Adobe Flash entry looked like a massive Webkinz advertisement :P Can I resurrect the Gnash/Gstreamer thread here? I sure could use help with getting mp3 sound working on Gstreamer in so we can put a step-by-step entry for people who are not as well-versed in Linux (that includes me!) on how to get sound working at http://wiki.laptop.org/go/Gnash The old thread here was left unresolved and hanging and I still haven't gotten Gnash sound/Gstreamer mp3 working on the XO 8.2.0. It's been suggested at the Gnash dev mailing list that alternative sound codecs such as AMR be used instead by authors (I used it before for a Flash Lite game because MP3 playback wasn't supported on some phones) but frankly this is wishful thinking as almost every single .SWF out there is published with MP3 sound. Anyway, for the benefit of the folks who prefer to use Gnash to Adobe Flash, it would be really great if we could outline that sound howto on the Gnash wiki entry :) Anyway, why does this wiki page tell you to enter sudo su - when every other page I've seen says su - (or su -l) ? `sudo su -` seems redundant. Fixed it. Happy New Year, all! -Naz -- Carlos Nazareno http://www.object404.com -- interactive media specialist zen graffiti studios http://www.zengraffiti.com -- Philippine Flash ActionScripters http://www.phlashers.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] XS 0.5.1-dev03 with ejabberd goodness, kernel bling, Access Point workingness... looking for xmas testers
2008/12/31 David Leeming leem...@pipolfastaem.gov.sb I want to do a new install but can you let me know if I can install Samba and how to set up access to a shared folder on a Windows PC on the LAN as I have a large content collection and it takes ages to copy it all again by flash drive. Or maybe there is a better way to do it. I was curious about that, too, so I looked into other alternatives as Samba can sometimes be a pain to configure. It's also yet another service to run on the XS. I found an sshfs utility for Windows called Dokan. And it's free for non-commercial purposes! This might make more sense than fooling with Samba, especially if you only have one Windows machine to deal with. The Dokan library and Doken SSHFS packages are at http://dokan-dev.net/en/download/. I also had to install the Microsoft Visual C++ package mentioned on that site, the .NET Framework (which was 55 MB), and Windows Installer 3.1. There's a nice GUI to enter in your ssh login info and mount points. I connected and now /home/anna on the XS is mounted read/write on N: on an XP machine. Anna Schoolfield Birmingham ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
