On Mon, 2010-12-13 at 17:06 -0800, ext Niels Mayer wrote: > On Fri, Dec 10, 2010 at 8:10 AM, Andrew Green <[email protected]> wrote: > > What API should a phone app use to enable speakerphone? > > > > Or phrased another way the Policy Framework handles the audio routing so > > what should be done to cause the PF to make a policy decision to route audio > > to the speakers? > > > > I'm not trying to implement this immediately just planning for the future. > > The following script may provide some clues: > > [me...@localhost ~]$ cat /usr/bin/n900-alsamixer-set-speakers.sh > #!/bin/sh > amixer -D hw:0 set PCM 100% > > amixer -D hw:0 set 'HP DAC' 75% on > > amixer -D hw:0 set 'Left DAC_L1 Mixer HP' on > amixer -D hw:0 set 'Right DAC_R1 Mixer HP' on > > amixer -D hw:0 set 'Speaker Function' On
Please, don't even try to do that. Applications should never try fiddling around directly with ALSA controls and in most setups will be actively prevented from doing so. Otherwise you end up interfering with some of the algorithms in pulseaudio which use the same controls. On some hardware, eg. the N900, in the worst case you might end up bypassing speaker protection and blowing your speakers out. For audio rendering applications should always go through PA, either using a high-level interface/abstraction like gstreamer, mafw, etc, or using the native PA API if a lower-level interface is necessary. For audio routing applications should trust policy to do the routing and use the routing override interface if necessary. The latter is a bit awkward but we'll try to improve it. > > -- Niels > http://nielsmayer.com > br, Krisztian > PS: other scripts doing similar things w/ ALSA: Again, take those as an example of what applications should not do ;-) I'd simply consider those as documenting via examples the ALSA HW abstraction. > > -rwxr-xr-x 1 root root 176 Oct 28 17:31 /usr/bin/n900-alsamixer-set-dmic.sh > -rwxr-xr-x 1 root root 261 Oct 28 17:31 > /usr/bin/n900-alsamixer-set-earpiece.sh > -rwxr-xr-x 1 root root 52 Oct 28 17:31 /usr/bin/n900-alsamixer-set-fm_off.sh > -rwxr-xr-x 1 root root 86 Oct 28 17:31 /usr/bin/n900-alsamixer-set-fm_on.sh > -rwxr-xr-x 1 root root 622 Oct 28 17:31 > /usr/bin/n900-alsamixer-set-fmrx_bypass.sh > -rwxr-xr-x 1 root root 270 Oct 28 17:31 /usr/bin/n900-alsamixer-set-fmtx.sh > -rwxr-xr-x 1 root root 328 Oct 28 17:31 > /usr/bin/n900-alsamixer-set-headphone.sh > -rwxr-xr-x 1 root root 481 Oct 28 17:31 > /usr/bin/n900-alsamixer-set-headset_mic.sh > -rwxr-xr-x 1 root root 3516 Oct 28 17:31 > /usr/bin/n900-alsamixer-set-shutdown.sh > -rwxr-xr-x 1 root root 208 Oct 28 17:31 > /usr/bin/n900-alsamixer-set-speakers.sh > > PPS: Just when i thought I'd worked with a complicated soundchip ( > c.f. http://mudita24.googlecode.com ) ... the "amixer" results of > meego indicate an equally complicated soundchip; where random hacking > could render your system somewhat useless... is there documentation on > all these values?: http://nielsmayer.com/meego/n900-card0-amixer.txt . > The only chip mentioned by name is > http://focus.ti.com/lit/ds/symlink/tpa6130a2.pdf "TPA6130A2 Headphone" > _______________________________________________ > MeeGo-handset mailing list > [email protected] > http://lists.meego.com/listinfo/meego-handset _______________________________________________ MeeGo-handset mailing list [email protected] http://lists.meego.com/listinfo/meego-handset
