Reply
Thread Tools
Posts: 2,076 | Thanked: 3,268 times | Joined on Feb 2011
#11
There are a few ways to tackle this.

1) One as mentioned in 3d OSS graphics thread, get wireshark-like utility to dump all that is going between alsaped and kernel and reverse engineer that (unless meego/mer/nemo/ubuntu guys chime in, 11.10 did play half of its welcome tone for me, so getting sound playing without nokia package is definitely possible, at least halfway), might be overkill as this daemon is probably not as obfuscated as 3d graphics drivers (from the 3d thread link: "It is worth pointing out that that GPL-licensed Kernel Driver is pretty much useless as far as contributing to a fully Free Software compliant 3D userspace library: the Kernel-space Driver is merely a communications channel. This state of affairs (GPL kernel driver plus proprietary userspace library) is common amongst pretty much every single embedded 3D engine, and contributes greatly to the confused and erroneous belief that there already exists Free Software compliant OpenGL libraries for embedded CPUs.

Modification of the Linux Kernel driver is at least possible, and will allow print-outs to be taken of the data passing through it. (As there is no encryption, this is perfectly possible and reasonable). From these print-outs, it will be possible to write simple OpenGL applications that perform simple 3D operations, one by one, and the results observed, recorded and then, ultimately, replayed. This well-known method has already been utilised to great effect, to reverse-engineer the majority of Samsung's FIMD-3D engine present in the S3C6410 and the S5PC100.")


2) Krisztian Litkey mentioning alsaped massacre build, his pulseaudio approach could be similar. ("* Bumping the version due to the problem with the alsaped massacre build. http://meego.gitorious.org/maemo-multimedia/pulseaudio-policy-enforcement/commit/72f074aeeb20b1ac7c7cae099ec653a5a868c9eb/diffs?diffmode=sidebyside&fragment=1" or him contributing later on, can't tell)


3) IDA Pro (or the like):

HEXARML ARM Decompiler Base License (Linux) 1722 EUR

Willing to bet 100$ some member of maemo community got IDA Pro license and could dump its analysis here for further reverse engineering.

EDIT: And why I am willing to bet 100$ is this: http://talk.maemo.org/showpost.php?p...5&postcount=26 this community has incredible people, getting the right ones on a project results in crazy stuff like KP/CSSU, reverse engineering guys with interested parties in digging through all the blob-**** could open whole of maemo (I really hope so)

Last edited by szopin; 2012-04-04 at 21:45.
 

The Following 4 Users Say Thank You to szopin For This Useful Post:
Posts: 1,225 | Thanked: 1,905 times | Joined on Feb 2011 @ Quezon City, Philippines
#12
Okay, I just threw this into IDA (with the ARM disassembler) targeting ARMv7-A&R.

http://dl.dropbox.com/u/60358506/alsaped.html
__________________
N9 PR 1.3 Open Mode + kernel-plus for Harmattan
@kenweknot, working on Glacier for Nemo.
 
javispedro's Avatar
Posts: 2,355 | Thanked: 5,249 times | Joined on Jan 2009 @ Barcelona
#13
alsaped just listens for a d-bus message that has basically _one_ parameter and then proceeds to fed to the alsa mixer the contents of the configuration file associated with that word. e.g https://github.com/javispedro/cfmrad...routing.c#L108. It's basically a glorified amixer wrapper.

There's no need to reverse engineer _anything_ and the replacement on Meego and Harmattan is a feature of PulseAudio (upstream feature, also used in the desktop) called card profiles.
 

The Following 5 Users Say Thank You to javispedro For This Useful Post:
Posts: 2,076 | Thanked: 3,268 times | Joined on Feb 2011
#14
Hurrian: Thanks, now just need to take a crash course in ARM disassembly, or...

javispedro: your approach would be?
sudo /usr/sbin/alsaped -p 4 -f /usr/share/policy/etc/current/alsaped.conf -vrbe
in one window with dbus-monitor in another and then: play an mp3 file, make a call, answer a call, change volume... (probably also dump alsamixer calls?) and reconstruct alsaped this way?
 

The Following User Says Thank You to szopin For This Useful Post:
Posts: 838 | Thanked: 3,384 times | Joined on Mar 2009
#15
(just sketching one idea)
When alsaped is running.

run
Code:
alsactl store
It will make configuration file to the /var/lib/alsa/asound.state
Save file.

Plug headphones, run
Code:
alsactl store
Configuration file differs (as expected).

This will work also:
Code:
alsactl store -f filename
Then there are
Code:
alsactl restore -f filename
but it seems to not work when alsaped is running.
 

The Following 2 Users Say Thank You to AapoRantalainen For This Useful Post:
Posts: 2,076 | Thanked: 3,268 times | Joined on Feb 2011
#16
Tried that, somewhat works: restoring file from before plugging the headphones, will stop the sound, though not direct the output to speaker. Loading file from plugged state will restore the sound in headphones.
Seems the alsactl restore does only second hald of this:

[range 0 - 127, step 0] [127]
16:49:55 alsaped: got actions (txid:0)
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
16:49:55 alsaped: Got routing reuest: 'sink' -> 'headset'
16:49:55 alsaped: Routing sink to 'headset'
16:49:55 alsaped: set outband execution (line 691, delay 100msec)
16:49:55 alsaped: Got routing reuest: 'source' -> 'headset'
16:49:55 alsaped: Routing source to 'headset'
16:49:55 alsaped: actions succeeded
16:49:55 alsaped: Not sending status message since transaction ID is 0
16:49:55 alsaped: Element value changed numid=12,iface=MIXER,name='HP DAC Output Volume',values=2
[range 0 - 6, step 0] [6]
16:49:55 alsaped: Element value changed numid=1,iface=MIXER,name='PCM Playback Volume',values=2
[range 0 - 127, step 0] [0]
16:49:55 alsaped: Element value changed numid=64,iface=MIXER,name='Speaker Function'
['Off', 'On'] [Off]
16:49:55 alsaped: Element value changed numid=16,iface=MIXER,name='HPCOM DAC Playback Switch',values=2
['on', 'off'] [off]
16:49:55 alsaped: Element value changed numid=61,iface=MIXER,name='Left DAC_L1 Mixer HP Switch'
['on', 'off'] [off]
16:49:55 alsaped: Element value changed numid=55,iface=MIXER,name='Right DAC_R1 Mixer HP Switch'
['on', 'off'] [off]
16:49:55 alsaped: Element value changed numid=65,iface=MIXER,name='Jack Function'
['Off', 'Headphone', 'Headset', 'Mic', 'ECI Headset', 'TV-OUT'] [Headset]
16:49:55 alsaped: Element value changed numid=59,iface=MIXER,name='Left DAC_L1 Mixer Line Switch'
['on', 'off'] [on]
16:49:55 alsaped: Element value changed numid=53,iface=MIXER,name='Right DAC_R1 Mixer Line Switch'
['on', 'off'] [on]
16:49:55 alsaped: Element value changed numid=3,iface=MIXER,name='Line DAC Playback Switch',values=2
['on', 'off'] [on]
16:49:55 alsaped: Element value changed numid=2,iface=MIXER,name='Line DAC Playback Volume',values=2
[range 0 - 118, step 0] [118]
16:49:55 alsaped: Element value changed numid=67,iface=MIXER,name='Input Select'
['ADC', 'Digital Mic'] [ADC]
16:49:55 alsaped: Element value changed numid=49,iface=MIXER,name='Left PGA Mixer Line1L Switch'
['on', 'off'] [on]
16:49:55 alsaped: Element value changed numid=23,iface=MIXER,name='ADC HPF Cut-off',values=2
['Disabled', '0.0045xFs', '0.0125xFs', '0.025xFs'] [Disabled]
16:49:55 alsaped: Element value changed numid=21,iface=MIXER,name='PGA Capture Volume',values=2
[range 0 - 119, step 0] [48]
16:49:55 alsaped: Element value changed numid=22,iface=MIXER,name='PGA Capture Switch',values=2
['on', 'off'] [on]
16:49:55 alsaped: Element value changed numid=48,iface=MIXER,name='Left Line1L Mux'
['single-ended', 'differential'] [differential]
16:49:55 alsaped: Element value changed numid=44,iface=MIXER,name='Right PGA Mixer Line1L Switch'
['on', 'off'] [on]
16:49:55 alsaped: Element value changed numid=12,iface=MIXER,name='HP DAC Output Volume',values=2
[range 0 - 6, step 0] [6]
16:49:55 alsaped: Element value changed numid=12,iface=MIXER,name='HP DAC Output Volume',values=2
[range 0 - 6, step 0] [6]
16:49:55 alsaped: Element value changed numid=3,iface=MIXER,name='Line DAC Playback Switch',values=2
['on', 'off'] [on]
16:49:55 alsaped: Element value changed numid=2,iface=MIXER,name='Line DAC Playback Volume',values=2
[range 0 - 118, step 0] [118]
16:49:55 alsaped: Element value changed numid=21,iface=MIXER,name='PGA Capture Volume',values=2
[range 0 - 119, step 0] [48]
16:49:55 alsaped: Element value changed numid=22,iface=MIXER,name='PGA Capture Switch',values=2
['on', 'off'] [on]
16:49:55 alsaped: outband execution of rules succeded (line 691)
16:49:55 alsaped: Element value changed numid=1,iface=MIXER,name='PCM Playback Volume',values=2
[range 0 - 127, step 0] [127]
16:49:55 alsaped: Element value changed numid=1,iface=MIXER,name='PCM Playback Volume',values=2
[range 0 - 127, step 0] [127]
16:49:55 alsaped: Element value changed numid=1,iface=MIXER,name='PCM Playback Volume',values=2
[range 0 - 127, step 0] [127]
^C16:50:24 alsaped: Exiting now ...
(this is from plugging in)
only the elements get their values changed, routing doesn't happen.
 

The Following 2 Users Say Thank You to szopin For This Useful Post:
javispedro's Avatar
Posts: 2,355 | Thanked: 5,249 times | Joined on Jan 2009 @ Barcelona
#17
Originally Posted by szopin View Post
javispedro: your approach would be?
sudo /usr/sbin/alsaped -p 4 -f /usr/share/policy/etc/current/alsaped.conf -vrbe
in one window with dbus-monitor in another and then: play an mp3 file, make a call, answer a call, change volume... (probably also dump alsamixer calls?) and reconstruct alsaped this way?
I suggest that you just read and comprehend the configuration file -- all of the logic is in there in plain text. In case it wasn't clear..
1. Alsaped waits for a D-Bus message
2. Alsaped parses configuration file section name that was indicated in the d-bus message
3. Alsaped blindly sets all mixer controls as indicated in the configuration file to the values indicated in the configuration file.

It is as simple as that, and if you just read the configuration file and use amixer to set the controls specified there you will be able to reproduce all the "magic". I did that when I was developing C FM Radio...
 

The Following 8 Users Say Thank You to javispedro For This Useful Post:
Posts: 838 | Thanked: 3,384 times | Joined on Mar 2009
#18
Code:
headphone        = pcm-volume: 0%
will be
Code:
amixer -c 0 sset PCM 0
And
Code:
headphone        = speaker-switch: Off
will be

Code:
amixer -c 0 sset 'Speaker Function' Off
 

The Following 2 Users Say Thank You to AapoRantalainen For This Useful Post:
javispedro's Avatar
Posts: 2,355 | Thanked: 5,249 times | Joined on Jan 2009 @ Barcelona
#19
Originally Posted by AapoRantalainen View Post
Code:
headphone        = pcm-volume: 0%
will be
Code:
amixer -c 0 sset PCM 0
Exactly. The mappings between the "short identifiers" (pcm-volume) and the ALSA hctl names are defined at the top of the configuration file. Example:
Code:
[control]                                               
id         = pcm-volume                            
card       = RX51                                  
interface  = MIXER                                 
name       = "PCM Playback Volume"
(Therefore actual control would be " numid=1,iface=MIXER,name='PCM Playback Volume' ". However, the "PCM" sctl that you used is an alias to that, afaik).
 

The Following 6 Users Say Thank You to javispedro For This Useful Post:
Posts: 2,076 | Thanked: 3,268 times | Joined on Feb 2011
#20
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"
               }
            ]
         ]
      )

Last edited by szopin; 2012-04-05 at 17:13. Reason: added dbus output
 

The Following 2 Users Say Thank You to szopin For This Useful Post:
Reply


 
Forum Jump


All times are GMT. The time now is 22:36.