maemo.org - Talk - What we know about alsa-policy-enforcement and alsaped?

maemo.org - Talk (https://talk.maemo.org/index.php)

- Nokia N900 (https://talk.maemo.org/forumdisplay.php?f=44)

- - What we know about alsa-policy-enforcement and alsaped? (https://talk.maemo.org/showthread.php?t=83447)

Re: What we know about alsa-policy-enforcement and alsaped?

Quote:

Originally Posted by szopin (Post 1188485)

would using this config file be ok with Nokia(assuming someone writes a replacement for alsaped)?

I think it comes from http://wiki.maemo.org/Fremantle_clos...-settings-rx51

And I think it can't be used as it.

Maybe it can be rewritten to runnable script. So alsaped would not read it, but execute it with parameter.

--
This is mentioned be Meego's equivalent for policy, but it doesn't look same (for me):
https://meego.gitorious.org/maemo-mu...settings-basic

Re: What we know about alsa-policy-enforcement and alsaped?

Well, this answers the question:

Where this file comes /usr/share/policy/etc/current/alsaped.conf ? It is not in package.

from wiki :( Would be good if a law student could chime in how this can be opensourced (dumping state of all controls in each combination could be a way, but is it legally ok? we are just pulling what nokia devised for all combinations in the end)

Re: What we know about alsa-policy-enforcement and alsaped?

If it is only one achievable way of doing this (properly), then we can re-use mentioned method, (written from scratch). Of course, definite legal answer can't be presented, as legislation wary from country to country - what is OK in EU may be "threat against digital shitlenia blabla" in US.

/Estel

Re: What we know about alsa-policy-enforcement and alsaped?

Quote:

Originally Posted by AapoRantalainen (Post 1188517)

This is mentioned be Meego's equivalent for policy, but it doesn't look same (for me):
https://meego.gitorious.org/maemo-mu...settings-basic

The replacement in Meego is PulseAudio's card profiles feature (upstream feature!, so no code). The configuration files for that are in here: http://meego.gitorious.org/meego-dev...sa-mixer/paths

They are actually very similar; probably a regex could transform from one syntax to the other ;)

Regarding the audio contexts, I don't remember anything about them atm, so either they were not important or other component handled that.

Re: What we know about alsa-policy-enforcement and alsaped?

Hurrian's dump could tell more about routing reuest vs context reuest:

routing reuest:
text:00012390
rodata:000164F0

context reuest:
text:000125A0
rodata:00016568

The subroutines are around these addresses. Definitely context is parsed/actioned upon. If this has some deeper logic needs to be evaluated by someone with arm-reveng skills.

Re: What we know about alsa-policy-enforcement and alsaped?

Quote:

Originally Posted by szopin (Post 1188485)

Thanks javispedro, that clears up almost everything. Actually everything past this point:

16:49:55 alsaped: Got routing reuest: 'sink' -> 'headset'
16:49:55 alsaped: Routing sink to 'headset'

What about context setting?

16:49:55 alsaped: parsing context
16:49:55 alsaped: Got context reuest: 'jackbias' 'off'
16:49:55 alsaped: Setting context 'jackbias-off'
16:49:55 alsaped: Got context reuest: 'call_audio_type' 'none'
16:49:55 alsaped: Setting context 'call_audio_type-none'
16:49:55 alsaped: Got context reuest: 'call' 'inactive'
16:49:55 alsaped: Setting context 'call-inactive'
16:49:55 alsaped: Got context reuest: 'mode' 'media'
16:49:55 alsaped: Setting context 'mode-media'
16:49:55 alsaped: parsing audio routes

jackbias is a sctl, but mode-media for example is not in the conf file, also can logic of parsing change based on context?
On another thing, in the context of FREEmantle, would using this config file be ok with Nokia(assuming someone writes a replacement for alsaped)? Dumping with alsactl might be a way out of this (though it seems to have missed some settings with store/restore on plugged headset).

edit: just for reference, managed to catch the dbus message for plug:

Code:

      dict entry(

         string "com.nokia.policy.context"

         array [

            array [

               struct {

                  string "variable"

                  variant                      string "jackbias"

               }

               struct {

                  string "value"

                  variant                      string "off"

               }

            ]

            array [

               struct {

                  string "variable"

                  variant                      string "call_audio_type"

               }

               struct {

                  string "value"

                  variant                      string "none"

               }

            ]

            array [

               struct {

                  string "variable"

                  variant                      string "call"

               }

               struct {

                  string "value"

                  variant                      string "inactive"

               }

            ]

            array [

               struct {

                  string "variable"

                  variant                      string "mode"

               }

               struct {

                  string "value"

                  variant                      string "media"

               }

            ]

         ]

      )

      dict entry(

         string "com.nokia.policy.audio_route"

         array [

            array [

               struct {

                  string "type"

                  variant                      string "sink"

               }

               struct {

                  string "device"

                  variant                      string "headset"

               }

               struct {

                  string "mode"

                  variant                      string "hs"

               }

               struct {

                  string "hwid"

                  variant                      string "na"

               }

            ]

            array [

               struct {

                  string "type"

                  variant                      string "source"

               }

               struct {

                  string "device"

                  variant                      string "headset"

               }

               struct {

                  string "mode"

                  variant                      string "na"

               }

               struct {

                  string "hwid"

                  variant                      string "na"

               }

            ]

         ]

      )

Hi, can you create dbus call for jackbias-on? I think about solution without other hacks. Same dbus call which use Call application for enabling headset button...

Re: What we know about alsa-policy-enforcement and alsaped?

Quote:

Originally Posted by pali (Post 1238286)

Hi, can you create dbus call for jackbias-on? I think about solution without other hacks. Same dbus call which use Call application for enabling headset button...

Attached is log from inserting headphones while call is taking place, should set jackbias on

Re: What we know about alsa-policy-enforcement and alsaped?

@szopin: Thanks!

One question, do you know which application sending that dbus signal?

Re: What we know about alsa-policy-enforcement and alsaped?

I believe it's alsaped, if you run
sudo /usr/sbin/alsaped -p 4 -f /usr/share/policy/etc/current/alsaped.conf -vrbe
you can see all it is reacting to.

Re: What we know about alsa-policy-enforcement and alsaped?

alsaped is listening for X events and apply it.

If these signals are really sent from alsaped, how to tell alsaped to turn on jackbias?

I'm trying to find right way to enable jackbias in maemo.