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
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
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
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
Re: voip on Debian
On Thu, Oct 2, 2008 at 8:44 AM, Davide Scaini [EMAIL PROTECTED] wrote: Ekiga? did you tryed that on [EMAIL PROTECTED] so curious! I haven't, but I see no reason why it wouldn't work. It doesn't do IAX though, only SIP. And sip is problematic behind a NAT firewall. On Thu, Oct 2, 2008 at 2:56 PM, Esben Stien [EMAIL PROTECTED] wrote: Asterisk is dead. Long live freeswitch. Didn't you get the memo?;) I was under the impression that freeswitch was more geared to low level operations, carrier level stuff.(?) -- View this message in context: http://n2.nabble.com/voip-on-Debian-tp842903p1134642.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: voip on Debian
As of now, I'm using asterisk on debian to connect to an IAX2 provider. (diamoncard.us) There is a far end echo, that is being caused by asterisk on the Freerunner. Other than that, it is working perfectly. I don't know much about the FSO framework or zhone, but it would be trivial (from the asterisk end) to use zhone as the front end, as it would only take sending asterisk manager commands to control the console. Configuration of asterisk with a gui would be a sticking point, but not too complicated by any means. I'm still working on eliminating the echo, but I have a feeling that nothing short of a recompile will work (or a channel driver for the wolfson codec instead of using alsa, both of which I am ignorant about). I saw the asterisk .ipk in the community repo, does anyone know the source of that package, or who compiled it? -- View this message in context: http://n2.nabble.com/voip-on-Debian-tp842903p1132559.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
voip on Debian
I've had a lot of success running both twinkle and asterisk and I thought I'd share my experiences. Twinkle works well, but the gui is limiting on the touchscreen. I think once configured properly asterisk will make an excellent voip backend for the neo. You can control it through asterisk manager commands by writing text strings to a socket, and which has hooks for most languages I'm sure. The difficult part is getting a good set of configuration files for asterisk. I think for the most part I have a good setup for sip. iax could be configured too (important I think for the encryption). Heres the steps as well as I can remember: 1.) You need the alsa state for voip handset. Can be got here: http://svn.openmoko.org/trunk//src/target/audio/om-gta02/ This goes in /usr/share/openmoko/scenarios/ load it with the command : alsactl -f /usr/share/openmoko/scenarios/voip-handset.state restore 2.) Install asterisk, or twinkle, (or whatever, I got those two to work). In any program other than asterisk, you must enter your sip server info. For asterisk you need these changes: -modules.conf: change the sound module from oss to alsa (about halfway down) -alsa.conf: uncomment the audio devices and use `plughw` as the devices instead of `hw` like this input_device=plughw:0,0 set autoanswer=no -sip.conf: you need to set your realm for your sip server set an outbound sip registration: register = user:[EMAIL PROTECTED] set authentication credentials for outgoing calls: auth=user:[EMAIL PROTECTED] I recommend using disallow=all allow=ulaw or alaw, to avoid stressing the cpu, unless you have a slow net connection. -extensions.conf: you need to set up extensions to forward to your sip service exten = _1NXXNXX,1,Dial(SIP/[EMAIL PROTECTED]) It really helps to have an asterisk server that isn't NATed to test with If someone out there has the skills to make a gui, I can do the backend asterisk stuff. There is the potential to do some really cool stuff with asterisk it has quite a bit of functionality. -- View this message in context: http://n2.nabble.com/voip-on-Debian-tp842903p842903.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
