Re: XOs with no sound
Happy New Year. We don't use the Measure Activity. Here are the most frequently used Activities using sound: - Scratch version 11 (with resume sound problem, ticket #6201) - Record version 59 - Browse version 98 with Adobe flash plugin version 10.0.12.36 (gnash deinstalled) for a flash based English learning program - Gcompris bundle Version 10 - Speak version 9 Recording with Scratch works with No sound XOs even so Capture volume is set to 0. I will keep an eye on the alsamixer when I use these activities. Regards, Philipp James Cameron wrote: 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? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
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
XOs with no sound
Hi The sound of 5 of our 100 XOs doesn't work anymore. The hardware test is okay (sound works), but all the sugar activities I tested (Scratch, TamTamMini, Speak, Gcompris) don't have sound. Rebooting the XO doesn't help. I checked the sugar log files and /var/log/messages, but couldn't find any sound related warnings or errors. We are running build 767, but I have seen the same problem with build 708 (but not that often). Reinstalling the OS solves the problem, but I would prefer an easier solution. I checked if such a bug is reported, but couldn't find a ticket (the sound resume problem of ticket 6201 is normally solved with a reboot). Since I don't know how to reproduce the problem, I would like to localize it before opening a ticket. What can I do to localize the problem (e.g. low level sound tests)? Is it possible that running out of battery while playing sound can have such an effect or could it be related to the resume problem of ticket 6201 (we had that problem very often with Scratch when the experimental power management was switched on )? Regards, Philipp Pepyride School Cambodia ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XOs with no sound
I have seen this problem when the alsamixer settings have become messed up. Seems like there are one or 2 processes that occasionally write to the alsamixer config file. You can alter the settings by running the graphical program /usr/bin/ alsamixer from the terminal. There is also a command line program / usr/sbin/alsactl but being late at night I can't remember the syntax off hand. On Dec 30, 2008, at 12:12 AM, Philipp Kocher wrote: Hi The sound of 5 of our 100 XOs doesn't work anymore. The hardware test is okay (sound works), but all the sugar activities I tested (Scratch, TamTamMini, Speak, Gcompris) don't have sound. Rebooting the XO doesn't help. I checked the sugar log files and /var/log/messages, but couldn't find any sound related warnings or errors. We are running build 767, but I have seen the same problem with build 708 (but not that often). Reinstalling the OS solves the problem, but I would prefer an easier solution. I checked if such a bug is reported, but couldn't find a ticket (the sound resume problem of ticket 6201 is normally solved with a reboot). Since I don't know how to reproduce the problem, I would like to localize it before opening a ticket. What can I do to localize the problem (e.g. low level sound tests)? Is it possible that running out of battery while playing sound can have such an effect or could it be related to the resume problem of ticket 6201 (we had that problem very often with Scratch when the experimental power management was switched on )? Regards, Philipp Pepyride School Cambodia ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XOs with no sound
How to fix no sound caused by operating system. 1. obtain the root prompt, e.g. by starting the Terminal activity and clicking on become root button, 2. if you wish to find out in which way the settings have been corrupted, copy the file /etc/asound.state before proceeding, cp /etc/asound.state /home/olpc/asound.state.orig 3. obtain a copy of /etc/asound.state from a working XO, or from a reinstalled XO, and place it in /etc/asound.state on the failed XO, 4. restore the settings from the file, alsactl restore 5. test that sound now works. Note: there is a possibility that the build 767 ALSA saved state file is in some other place. I've not checked. I found out where the file was on Joyride 2612 using a command: strace -e open alsactl restore -- James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XOs with no sound
Hi James et al, That's great debugging and repair info. I especially like the use of the stack trace command! That's a great trick for hunting down which process is calling what files. Do we know how this gets in a failed state to begin with? I read the headlines of them most recent 100 bugs with sound in them and I didn't see anything that would cause this. I only saw 3 old, closed bugs with alsactl in them. If we have an ideas on why or how this happens, let's file a bug and I can track it for 9.1. Thanks, Greg S * Date: Tue, 30 Dec 2008 20:46:39 +1100 From: qu...@laptop.org Subject: Re: XOs with no sound To: Philipp Kocher philipp.koc...@gmx.net Cc: devel@lists.laptop.org Message-ID: 20081230094639.ga12...@us.netrek.org Content-Type: text/plain; charset=us-ascii How to fix no sound caused by operating system. 1. obtain the root prompt, e.g. by starting the Terminal activity and clicking on become root button, 2. if you wish to find out in which way the settings have been corrupted, copy the file /etc/asound.state before proceeding, cp /etc/asound.state /home/olpc/asound.state.orig 3. obtain a copy of /etc/asound.state from a working XO, or from a reinstalled XO, and place it in /etc/asound.state on the failed XO, 4. restore the settings from the file, alsactl restore 5. test that sound now works. Note: there is a possibility that the build 767 ALSA saved state file is in some other place. I've not checked. I found out where the file was on Joyride 2612 using a command: strace -e open alsactl restore -- James Cameron mailto:qu...@us.netrek.org http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XOs with no sound
On Tue, Dec 30, 2008 at 09:32:38AM -0500, Greg Smith wrote: That's great debugging and repair info. I especially like the use of the stack trace command! That's a great trick for hunting down which process is calling what files. Actually, it's a system call tracing command. It can be used to show what a process is asking the kernel to do. Yes, it is an essential technical support tool. It can also be used on processes that are already running. Do we know how this gets in a failed state to begin with? No, not yet. I've two theories as to cause. Seeing the content of a failed /etc/asound.state file beside a working file from the same build would help confirm the theories. I hope these can be made available. My theories are: 1. one of the mixer controls was changed by an activity or other program, and not changed back, (this is the most likely), 2. some hitherto undetected defect in alsactl or the way it is being called by our OS build. The mixer is the hardware component that controls the many output volumes, the microphone sensitivity, and the use of the microphone input jack as a voltage sensor. The set of controls is referred to as the mixer settings. There are more controls in the set than are exposed to the Sugar or activity user. All the controls can be changed on the shell command line. The Sugar volume keys manipulate the main output volume. The Frame shows the current main output volume. The Measure activity manipulates the microphone and voltage sensor. The mixer settings are preserved over shutdown and reboot by the operating system. /etc/init.d/halt is where the mixer settings are saved. /etc/init.d/olpc-configure is where the mixer settings are restored. (I wonder why we want to save and restore mixer settings anyway? Would it not be better to set them to default on each boot?) I have excluded empty mixer settings file as a cause. If the file is empty, alsactl uses default settings, and these are not significantly different to the working settings. Tested on Joyride 2612. Revision to my previous instructions ... merely moving /etc/asound.state to another name and rebooting may solve the immediate problem though not the cause. -- James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XOs with no sound
What is the ticket number for that problem?
It seems like always the same 7 values are wrong.
There is a shorter solution:
1. Copy /etc/alsa/asound.state of a healthy XO to USB flash drive
2. Type alsactl -f /media/{flash_dirve_name}/asound.state restore on
the XO with no sound
Thanks
qu...@laptop.org wrote:
How to fix no sound caused by operating system.
1. obtain the root prompt, e.g. by starting the Terminal activity and
clicking on become root button,
2. if you wish to find out in which way the settings have been
corrupted, copy the file /etc/asound.state before proceeding,
cp /etc/asound.state /home/olpc/asound.state.orig
3. obtain a copy of /etc/asound.state from a working XO, or from a
reinstalled XO, and place it in /etc/asound.state on the failed XO,
4. restore the settings from the file,
alsactl restore
5. test that sound now works.
Note: there is a possibility that the build 767 ALSA saved state file is
in some other place. I've not checked. I found out where the file was
on Joyride 2612 using a command:
strace -e open alsactl 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 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 -- James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
