Re: Testing for audio playback
Here is my solution: I have modified neod executables here http://atariland.net/~dreilly/openmoko/neod/neod.tar.gz (source http://atariland.net/~dreilly/openmoko/neod/neod-src.tar.gz) to call out to a series of scripts (http://atariland.net/~dreilly/openmoko/neod/neod-conf.tar.gz) before and after every power management state (dim, blank, suspend). If the preXXX scripts return a non-zero exit code, the power management step will not be executed. See presuspend for an example. The included presuspend does the following: 1) Does not suspend when on AC power. 2) Does not suspend when the media player is running. 3) Attempts to not suspend when making a phone call. Note, since I cannot figure out a good way to check for this, I am looking for phone-kit to have a certain processor load. This is bad. Also in this neod one can set the times for each PM state via gconf: /desktop/openmoko/neod/dim_time /desktop/openmoko/neod/blank_time /desktop/openmoko/neod/suspend_time I am going on vacation in...2 minutes, so if you try it, beware. And, with ASU release looming this is probably mostly for naught. Have fun. On Tue, Aug 5, 2008 at 6:17 AM, Clemens Kirchgatterer [EMAIL PROTECTED] wrote: Dale Maggee [EMAIL PROTECTED] wrote: Sorry but I can't help, but I just wanted to say good luck with this, please keep us posted - I also find this annoying and I'd love to see it fixed! :) AFAIK, alsa has a plugin interface. we could install one, that periodically snoops into the stream and reports silence/noise via dbus. just my 2 cents ... clemens ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Dylan Maxwell Reilly ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Testing for audio playback
Dale Maggee [EMAIL PROTECTED] wrote: Sorry but I can't help, but I just wanted to say good luck with this, please keep us posted - I also find this annoying and I'd love to see it fixed! :) AFAIK, alsa has a plugin interface. we could install one, that periodically snoops into the stream and reports silence/noise via dbus. just my 2 cents ... clemens ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Testing for audio playback
Is there a way to test if sound is actually being pumped through the sound card? I can lsof various devices in /dev/snd or check /proc/asound/card0/pcmXX/sub0/status but those only tell me if a client is *connected*. Furthermore, I find it odd that the phone-kit does not seem to go through the alsa pcm but is only connected to /dev/snd/controlC0. Is there some way to know if the phone kit actually active? I'm probably just misunderstanding you, but why not test the sound card with a random audio file. Or run 'speaker-test'. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Testing for audio playback
I do not want to test if the sound is working but if audio is currently being processed by the card. For example, I find in bothersome that the freerunner will suspend while I am listening to music or using it as a phone. My hope is that there is/are some test(s) I can issue programatically that will tell me if one of those two events are occurring. As I mentioned, I can easily determine if a program has bound itself to the sound card (e.g., lsof) but not if audio is actually streaming. In particular, the phone kit is always bound to the card so lsof is not a useful test in that case. On Mon, Aug 4, 2008 at 9:50 AM, Yogiz [EMAIL PROTECTED] wrote: Is there a way to test if sound is actually being pumped through the sound card? I can lsof various devices in /dev/snd or check /proc/asound/card0/pcmXX/sub0/status but those only tell me if a client is *connected*. Furthermore, I find it odd that the phone-kit does not seem to go through the alsa pcm but is only connected to /dev/snd/controlC0. Is there some way to know if the phone kit actually active? I'm probably just misunderstanding you, but why not test the sound card with a random audio file. Or run 'speaker-test'. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Dylan Maxwell Reilly ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Testing for audio playback
Am Montag 04 August 2008 17:18:50 schrieb Dylan Reilly: I do not want to test if the sound is working but if audio is currently being processed by the card. This is only possible if you are using an audio daemon that supports something like that (e.g. pulseaudio) or if you are using a resource control system with only cooperative programs. The latter is what FSO aims to go towards with its Usage API. -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Testing for audio playback
I assumed as much. How does one check this condition in pulse, then? At least that could be a start. Does the phone-kit go directly to alsa or through pulseaudio? If the former, would it be feasible to route it through pulse audio? On Mon, Aug 4, 2008 at 1:40 PM, Michael 'Mickey' Lauer [EMAIL PROTECTED] wrote: Am Montag 04 August 2008 17:18:50 schrieb Dylan Reilly: I do not want to test if the sound is working but if audio is currently being processed by the card. This is only possible if you are using an audio daemon that supports something like that (e.g. pulseaudio) or if you are using a resource control system with only cooperative programs. The latter is what FSO aims to go towards with its Usage API. -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Dylan Maxwell Reilly ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Testing for audio playback
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | Am Montag 04 August 2008 17:18:50 schrieb Dylan Reilly: | I do not want to test if the sound is working but if audio is | currently being processed by the card. | | This is only possible if you are using an audio daemon that supports something | like that (e.g. pulseaudio) or if you are using a resource control system | with only cooperative programs. The latter is what FSO aims to go towards | with its Usage API. Or of course you could get stats or a flag from the driver... - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiXRXwACgkQOjLpvpq7dMo1ygCfZIeMru/EQHw5+WedmoAtDFx1 MAsAn2+hBSua8atZvralwsQUwp7EFXEE =ZQVy -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Testing for audio playback
Is that sort of thing in the alsa driver currently? That is relatively unknown territory for me. I have poked around /proc and /sys but found nothing of use. On Mon, Aug 4, 2008 at 2:07 PM, Andy Green [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | Am Montag 04 August 2008 17:18:50 schrieb Dylan Reilly: | I do not want to test if the sound is working but if audio is | currently being processed by the card. | | This is only possible if you are using an audio daemon that supports something | like that (e.g. pulseaudio) or if you are using a resource control system | with only cooperative programs. The latter is what FSO aims to go towards | with its Usage API. Or of course you could get stats or a flag from the driver... - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiXRXwACgkQOjLpvpq7dMo1ygCfZIeMru/EQHw5+WedmoAtDFx1 MAsAn2+hBSua8atZvralwsQUwp7EFXEE =ZQVy -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Dylan Maxwell Reilly ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Testing for audio playback
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | Is that sort of thing in the alsa driver currently? That is relatively | unknown territory for me. I have poked around /proc and /sys but found | nothing of use. I see decent looking stuff if I look at # cat /proc/asound/neo1973gta02/pcm0p/sub0/status idle -- closed catting /dev/urandom /dev/dsp --- state: RUNNING trigger_time: 1217825794.241945000 tstamp : 1217825796.260579000 delay : 30988 avail : 1780 avail_max : 30782 - - hw_ptr : 16167 appl_ptr: 48935 I guess those numbers change if you are doing something. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiXS+cACgkQOjLpvpq7dMpOdwCbB1Dz3O0njBugVk7DzHpGj2c/ WdcAoICIaAcGkfSamgFPdNgTFBtyPu9Q =AQY8 -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Testing for audio playback
I am not sure it is all that useful. The RUNNING state is only set when an application grabs on to alsa, not when it is pumping data into it. As for the other numbers...they change over time even when there is no audio playing but pulseaudio is running. On Mon, Aug 4, 2008 at 2:35 PM, Andy Green [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | Is that sort of thing in the alsa driver currently? That is relatively | unknown territory for me. I have poked around /proc and /sys but found | nothing of use. I see decent looking stuff if I look at # cat /proc/asound/neo1973gta02/pcm0p/sub0/status idle -- closed catting /dev/urandom /dev/dsp --- state: RUNNING trigger_time: 1217825794.241945000 tstamp : 1217825796.260579000 delay : 30988 avail : 1780 avail_max : 30782 - - hw_ptr : 16167 appl_ptr: 48935 I guess those numbers change if you are doing something. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiXS+cACgkQOjLpvpq7dMpOdwCbB1Dz3O0njBugVk7DzHpGj2c/ WdcAoICIaAcGkfSamgFPdNgTFBtyPu9Q =AQY8 -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Dylan Maxwell Reilly ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Testing for audio playback
Just a heads up: I think that checking the status won't work with pulseaudio running under 2007.2, since pulseaudio continuously sends a stream of zeros to the sound card. I haven't tested it though. (there is a pulseaudio configuration option for this.) Also, I think having the applications disable suspend would be better than letting some system-level daemon guess what the appropriate behavior is. Then audio activity and suspend wouldn't be coupled (eg: tangoGPS while recording GPS tracks...). Also, applications already communicate with the rest of the system, so there's probably a framework for such hooks somewhere. For example, mediaplayer mutes/pauses when a phone call comes in... -Rusty ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Testing for audio playback
Am Montag 04 August 2008 20:07:56 schrieb Andy Green: Somebody in the thread at some point said: | Am Montag 04 August 2008 17:18:50 schrieb Dylan Reilly: | I do not want to test if the sound is working but if audio is | currently being processed by the card. | | This is only possible if you are using an audio daemon that supports something | like that (e.g. pulseaudio) or if you are using a resource control system | with only cooperative programs. The latter is what FSO aims to go towards | with its Usage API. Or of course you could get stats or a flag from the driver... Indeed. I wonder whether the alsa libraries have something like a currently connect client-statistics for dmix? Pulseaudio has that but it still seems a bit too heavy for our CPU. -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Testing for audio playback
I was thinking of that. My only concern is what to do if the application died and did not get to restore the suspend state back to its previous value. For what its worth, there is a gconf setting for the suspend state that can be set. Neod is supposed to monitor it but the gconf callback is not working for some reason. I am looking into that atm. Gconf would be the easy way for other apps to control the suspend state. On Mon, Aug 4, 2008 at 2:56 PM, Russell Sears [EMAIL PROTECTED] wrote: Just a heads up: I think that checking the status won't work with pulseaudio running under 2007.2, since pulseaudio continuously sends a stream of zeros to the sound card. I haven't tested it though. (there is a pulseaudio configuration option for this.) Also, I think having the applications disable suspend would be better than letting some system-level daemon guess what the appropriate behavior is. Then audio activity and suspend wouldn't be coupled (eg: tangoGPS while recording GPS tracks...). Also, applications already communicate with the rest of the system, so there's probably a framework for such hooks somewhere. For example, mediaplayer mutes/pauses when a phone call comes in... -Rusty ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Dylan Maxwell Reilly ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Testing for audio playback
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | Just a heads up: I think that checking the status won't work with | pulseaudio running under 2007.2, since pulseaudio continuously sends a | stream of zeros to the sound card. I haven't tested it though. | | (there is a pulseaudio configuration option for this.) Huh? What is the point of that? Shouldn't we turn it off, just for power / CPU wakes POV? | Also, I think having the applications disable suspend would be better | than letting some system-level daemon guess what the appropriate | behavior is. The advantage would be that it'll also work for apps that aren't aware of this API. | Then audio activity and suspend wouldn't be coupled (eg: tangoGPS while | recording GPS tracks...). Also, applications already communicate with | the rest of the system, so there's probably a framework for such hooks | somewhere. For example, mediaplayer mutes/pauses when a phone call | comes in... Well it's out of my scope really, but there's more that can be done with what is visible kernel side or on /sys, eg to see if GPS is powered as an input to suspendability decision in your scenario above. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiXWOIACgkQOjLpvpq7dMpyiwCfV4TuJEsq1jXXhPPuYQqxKP1F 5lcAn0dRPf5AprWeFUFA7Jb1VJSIQyxT =rVq9 -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Testing for audio playback
Also, I think having the applications disable suspend would be better than letting some system-level daemon guess what the appropriate behavior is. I advocate a principled application of the concept of 'init states' for the entire system, which deal with the running state of various subsystems through the proper use of /etc/init.d/ scripts mapped to various power levels .. If power/suspend has been initiated by the user, then let init start and stop and send messages and such, to the appropriate subsystems that need it, and leave it at that. If some daemon pops up and says 'the user wants init 10', and we've got 'init.d/rc10.d/S,K*' scripts that properly do whats required for init 10, then let init 10 be we're at the office, leave us alone. I know there are all sorts of reasons to abandon init to the wind, but since we're already using init to deal with different system states, if but with a veritable stinginess, then surely it could be expanded? ; -- Jay Vaughan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Testing for audio playback
somewhere. For example, mediaplayer mutes/pauses when a phone call comes in... -Rusty Really? In 2007.2? It doesn't do that for me! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Testing for audio playback
Maybe this is more of a standard linux question, but I don't know the answer regardless. Is there a way to test if sound is actually being pumped through the sound card? I can lsof various devices in /dev/snd or check /proc/asound/card0/pcmXX/sub0/status but those only tell me if a client is *connected*. Furthermore, I find it odd that the phone-kit does not seem to go through the alsa pcm but is only connected to /dev/snd/controlC0. Is there some way to know if the phone kit actually active? My ultimate goal is to stop the device from going into suspend mode when sound is being played. Thanks. -- Dylan Maxwell Reilly ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
