Re: Alsa state chooser

2009-01-28 Thread TL Mieszkowski




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

2009-01-28 Thread TL Mieszkowski


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

2009-01-28 Thread TL Mieszkowski



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

2009-01-27 Thread TL Mieszkowski



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


Re: Alsa state chooser

2009-01-27 Thread TL Mieszkowski

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

2009-01-27 Thread TL Mieszkowski



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


Alsa state chooser

2009-01-26 Thread TL Mieszkowski

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

2008-10-02 Thread TL Mieszkowski

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

2008-10-01 Thread TL Mieszkowski


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

2008-09-06 Thread TL Mieszkowski

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