Re: Alsa state chooser
On Thursday 29 January 2009, TL Mieszkowski wrote: Al Johnson wrote: On Wednesday 28 January 2009, TL Mieszkowski wrote: KaZeR wrote: First example on top of my head : you are listening to music via your headset, and you unplug it : if in a public place, it might be convenient to pause media player to avoid bothering your neighboors. My other phone behaves like that and i find it convenient and respectful for the other people. I'm nobody, but that is so contrived it comes no where near convincing me that such a non-UNIXy system is the right way. Contrived? It's an example of good behaviour by an existing phone, so it's a real world example. Actually, who cares if it's contrived or not? I thought that was what /dev/input/eventX was for. It is on the Freerunner and Neo1973, but probably isn't the same device on the a780, the e-ten glofiish M800 or any of the other devices FSO may support in future. Remember FSO is an abstraction layer for smartphones in general, not Openmoko in particular. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Alsa state chooser
TL Mieszkowski wrote: KaZeR wrote: First example on top of my head : you are listening to music via your headset, and you unplug it : if in a public place, it might be convenient to pause media player to avoid bothering your neighboors. My other phone behaves like that and i find it convenient and respectful for the other people. I'm nobody, but that is so contrived it comes no where near convincing me that such a non-UNIXy system is the right way. Some other examples: You may have one preferred volume for your headset, and another preferred volume for the loudspeaker. The media player can set correct volume at all times, upon receiving notification. Apps that don't care can ignore this particular event. I find it useful that the phone notices plug/unplug events. I ususally plug in the headset in order to listen to music. The display lights up, so I don't have to waste a screen press on that. I can start the music player directly, because the backlight came on automatically. Since I don't use headphones for anything else, I could customize this further to launch the music player when the headset gets plugged in. There is no such option without a notification interface. You may not find notification useful, but I don't see that as a reason to remove it entirely. Some people have uses for it. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Alsa state chooser
I can see how having the sound info in a stack might be useful (marginally, really), but I can't see it justifying the use of D-bus. I wouldn't say never, but I really can't think of any pressing reasons to want to know when the state changes. First example on top of my head : you are listening to music via your headset, and you unplug it : if in a public place, it might be convenient to pause media player to avoid bothering your neighboors. My other phone behaves like that and i find it convenient and respectful for the other people. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Alsa state chooser
KaZeR wrote: First example on top of my head : you are listening to music via your headset, and you unplug it : if in a public place, it might be convenient to pause media player to avoid bothering your neighboors. My other phone behaves like that and i find it convenient and respectful for the other people. I'm nobody, but that is so contrived it comes no where near convincing me that such a non-UNIXy system is the right way. -- View this message in context: http://n2.nabble.com/Alsa-state-chooser-tp224p2235224.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Alsa state chooser
On Wednesday 28 January 2009, TL Mieszkowski wrote: KaZeR wrote: First example on top of my head : you are listening to music via your headset, and you unplug it : if in a public place, it might be convenient to pause media player to avoid bothering your neighboors. My other phone behaves like that and i find it convenient and respectful for the other people. I'm nobody, but that is so contrived it comes no where near convincing me that such a non-UNIXy system is the right way. Contrived? It's an example of good behaviour by an existing phone, so it's a real world example. Several people have asked about unusual audio routing configurations for specific applications. If another app changes the mixer settings then these apps will not work correctly, so it would be beneficial for them to handle this gracefully. To do this they need notification of the change in mixer setting. Changing the entire mixer scenario strikes me as being too coarse a control, but I haven't heard of any better proposals for abstraction. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Alsa state chooser
Al Johnson wrote: On Wednesday 28 January 2009, TL Mieszkowski wrote: KaZeR wrote: First example on top of my head : you are listening to music via your headset, and you unplug it : if in a public place, it might be convenient to pause media player to avoid bothering your neighboors. My other phone behaves like that and i find it convenient and respectful for the other people. I'm nobody, but that is so contrived it comes no where near convincing me that such a non-UNIXy system is the right way. Contrived? It's an example of good behaviour by an existing phone, so it's a real world example. Ok, I can see someone wanting this behavior, however I still see it as very contrived. Not only contrived, it makes little sense. First, something already exists for this called a mute button, or pause button. If you don't want other people to hear what's going on... why did you unplug your headphone? If I unplug my headphone while listening to music, it means I want to listen to it on the speaker. Otherwise... why did you unplug it? Several people have asked about unusual audio routing configurations for specific applications. If another app changes the mixer settings then these apps will not work correctly, so it would be beneficial for them to handle this gracefully. To do this they need notification of the change in mixer setting. Sounds like those apps should have their own state file, and restore it when gaining focus. Of course I don't know which apps you're talking about, so I'm probably not seeing the reasons to want that. Changing the entire mixer scenario strikes me as being too coarse a control, but I haven't heard of any better proposals for abstraction. If you want finer control amixer or libasound are the simple ways to do it. Or the alternative, reinvent UNIX poorly with unnecessarily complex abstractions. -- View this message in context: http://n2.nabble.com/Alsa-state-chooser-tp224p2236253.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Alsa state chooser
Al Johnson wrote: On Wednesday 28 January 2009, TL Mieszkowski wrote: KaZeR wrote: First example on top of my head : you are listening to music via your headset, and you unplug it : if in a public place, it might be convenient to pause media player to avoid bothering your neighboors. My other phone behaves like that and i find it convenient and respectful for the other people. I'm nobody, but that is so contrived it comes no where near convincing me that such a non-UNIXy system is the right way. Contrived? It's an example of good behaviour by an existing phone, so it's a real world example. Actually, who cares if it's contrived or not? I thought that was what /dev/input/eventX was for. -- View this message in context: http://n2.nabble.com/Alsa-state-chooser-tp224p2236352.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Alsa state chooser
On Tuesday 27 January 2009, TL Mieszkowski wrote: I'm not sure what the status of the Dbus sound stuff is, but I wrote a little program to choose the alsa state file with a simple gui. Attached is the code in anyone is interested. All it is is 1 button for each state file, very simplistic, uses elementary. (which btw kicks ass Raster) You would run it like so: scalpel `ls -1 /usr/share/openmoko/scenarios/` meh, whatever, works for me -Tim http://n2.nabble.com/file/n224/scalpel.c scalpel.c The FSO API can list and change the alsa scenarios with stack based management. It will also send a signal on scenario change so that interested apps are aware of it. See: http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesmartphone.Device.Audio.html;hb=HEAD ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Alsa state chooser
Al Johnson wrote: The FSO API can list and change the alsa scenarios with stack based management. It will also send a signal on scenario change so that interested apps are aware of it. See: http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesmartphone.Device.Audio.html;hb=HEAD I can see how having the sound info in a stack might be useful (marginally, really), but I can't see it justifying the use of D-bus. I wouldn't say never, but I really can't think of any pressing reasons to want to know when the state changes. Maybe it's just lack of imagination. And as for playing sounds off the message bus, why? Am I wrong for instinctively hating D-bus, and finding any reason to not use it? Or at least only using it for things that must be asynchronous? Something I could see as useful is a signal when headphones are plugged in. I remember reading in the Wolfson Codec manual that it is possible, by monitoring voltages or some such, I imagine that would have to be done in the alsa plugin or maybe in the driver though. -- View this message in context: http://n2.nabble.com/Alsa-state-chooser-tp224p2228688.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Alsa state chooser
WM8753.pdf pg 27: MICBIAS CURRENT DETECT The WM8753L includes a microphone bias current detect circuit which allows the user to set thresholds for the microphone bias current, above which an interrupt will be triggered. There are two separate interrupt bits, MICDET to allow the user to e.g. distinguish between one or two microphones connected to the WM8753L, and MICSHT to detect a shorted microphone (mic button press). The thresholds for the microphone bias current are set by MBTHRESH[2:0], for MICDET, and MBSCTHRESH[1:0] for MICSHT. Thresholds for each code are shown in Table 15. The circuit is enabled by setting MBCEN. See the GPIO and Interrupt Controller sections for details on the interrupt and status readback for the microphone bias current detect. REGISTERBITLABEL DEFAULT DESCRIPTION ADDRESS R51 (33h) 5:4 MBSCTHRESH 00 Microphone Bias, Shorted Current Threshold Select 00: 500uA 01: 1000uA 10: 1600uA 11: 2300uA These values are for 3.3V supply and scale with supply voltage. 3:1 MBTHRESH 000 Microphone Bias, Current Threshold Select 000:250uA 001:410uA 160uA steps up to 111:1370uA These values are for 3.3V supply and scale with supply voltage. 0 MBCEN 0Mic Bias Current Comparator Circuit enable 0 : Comparator disabled 1 : Comparator enabled Table 15 Mic Bias Current Comparator Circuit Control -- View this message in context: http://n2.nabble.com/Alsa-state-chooser-tp224p2229301.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Alsa state chooser
On Wednesday 28 January 2009, TL Mieszkowski wrote: WM8753.pdf pg 27: MICBIAS CURRENT DETECT The WM8753L includes a microphone bias current detect circuit which allows the user to set thresholds for the microphone bias current, above which an interrupt will be triggered. I think this appears as /dev/input/eventX and should be available in FSO's rules.yaml if it isn't available as a direct notification. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Alsa state chooser
Al Johnson wrote: I think this appears as /dev/input/eventX and should be available in FSO's rules.yaml if it isn't available as a direct notification. Cool, thanks Al -- View this message in context: http://n2.nabble.com/Alsa-state-chooser-tp224p2229815.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Alsa state chooser
I'm not sure what the status of the Dbus sound stuff is, but I wrote a little program to choose the alsa state file with a simple gui. Attached is the code in anyone is interested. All it is is 1 button for each state file, very simplistic, uses elementary. (which btw kicks ass Raster) You would run it like so: scalpel `ls -1 /usr/share/openmoko/scenarios/` meh, whatever, works for me -Tim http://n2.nabble.com/file/n224/scalpel.c scalpel.c -- View this message in context: http://n2.nabble.com/Alsa-state-chooser-tp224p224.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
