[fso based] Simplified mixer app

Al Johnson openmoko at mazikeen.demon.co.uk
Sat Oct 3 15:59:08 CEST 2009


Thanks for the feedback. The local beer festival may slow down the fixes 
though. I'll try to pull everything into one reply...

On Friday 02 October 2009, Laszlo KREKACS wrote:
> There have been many attempts to implement volume control;)
> Angus looked into it, did two versions (gtk, and after elementary)....

This one is derived form Angus's fso-mixer.py, and the Advanced view should 
look and behave almost identically. The novel part is bringing several alsa 
controls into one slider, so I was hoping for feedback on how well that worked 
at avoiding distortion on the gsm mic or the earpiece. Having said that I can 
see that I may need to improve the GUI to get more people testing it, and to 
make it more useful for people :-)

> I have also researched some of the things.
> 
> Nice to see, that there is an another attempt. I hope you will done it
>  right;)
> 
> I have only one suggestion:
> Please implement a help button on every near every group, where you
> explain shortly the most essential infos about the options.

That seems reasonable. The aim is to have a single slider for each group in 
the simple view. Showing multiple sliders in the simple view is the fallback 
for where there isn't a lookup table for mapping them to a single slider yet. 
If I do it then it would appear for individual sliders whichever view they 
were in though.

> I just launched your program and it picked up the stereout .state file, and
> displayed the sliders. Screenshot:
> http://laszlo.krekacs.googlepages.com/fso-mixer-screenshot.png
> 
> The screenshot is a bit wrong, because it does show the "Stereo Out"
>  string, in the middle (above Microphone). So it looks normal in real life,
>  dunno why the
> screenshot didnt included it. (maybe it was rendering while captured the
>  screen)
> 
> I would like see the following help buttons:
> Stereo Out [help]
> Microphone [help]
> Speaker [help]

I would like you to see only one slider in the simple view ;-) I just need to 
assemble the lookup table. I should have done that before release since it's 
the first one people will see.

> Help of the Stere Out page should be something similar:
> """
> Stereo Out state is corresponds, when the phone is idle
> (ie waiting for incoming call, or playing music).
> Microphone is disabled in this state, and Speaker corresponds to
> the speaker at the bottom near to the Neo text.
> [Should show a picture with a neo indicating where the microphone and
> the speaker are.]
> """
> 
> Help of Microphone page should be something similar:
> """
> Mic2 corresponds to XXX alsa settings (or group of alsa settings)
> Mono corresponds to XXX alsa setting
> Mono Sidetone corresponds to XXX alsa setting.
> Microphone can be altered also by this alsa settings: XXX,YYY, ZZZ
> However it is strongly discouraged to touch them.

The names are those returned by pyalsaaudio for that channel, and match the 
ones in alsamixer. I'll see if it can give me anything else like channel 
number though, or perhaps code it into the lookup. I sense some refactoring 
coming on...

> Advices:
> The monoside tone is used for XXX. You should hear XXX, when you
> raise it. Highest state does not automatically means better/louder
> voice transmitted.
> 
> Also some other advices how to correctly adjust the sliders. Like on
> the wiki page:
> reduce #5 by some 15..30 steps
> do testcall:
> you get very low volume at far end. but tone should be clear, no
> clipping (sharp agressive noise)
> if there is clipping: reduce #48 by one step (i.e. to "2")
> then adjust #5 to your preferences and taste
> 
> """
> 
> Keep in mind that your program should be self-explanatory and
> useful for even for the first time user.

That's the aim.

> If you want the explanatory pictures, Im sure somebody can draw it
> for you. If nobody step up, I look into what can I make;)
> 
> 
> There is also some AT command to affect the voice quality.
> Mickey told me, that on his freerunner, value 4 works better then
> value 5 (the default).
> I think it should also be included in your program, to give the
> ability to play with it...
> (if the user are still not satisfied with the result).

There is an AT command for the gsm playback volume, and an fso call to adjust 
it. I haven't found anything that gives a setting to dB mapping for this 
function though, so I can't easily include it in the gain mapping. The best I 
could do at the moment is to add an extra slider for it in the GSM states. If 
I do that I should probably add sliders for the bluez headset controls too. 

> Usability reports:
> 
> IT is nice, that your program switch the display automagically when the
> incoming call happens.

You can thank Angus for that. I'm just building on his foundations.

> However I think these are defectives:
> 1. when clicking on save there is no report what you did exactly, and was
>  it successful.
> I think on shr, you should save the .state file to /usr/share/shr/scenarii/
>  dir. So I expect something similar:
> Copying /usr/share/shr/scenarii/stereout.state to
> ~/.simplemixer/backup/stereout-20091002-1424.state... Success!
> Overwriting /usr/share/shr/stereout.state... Success!
> Saving was successful, even after reboot you should have the same
> voice experience as now.

See reply to later message on this point below...

> 2. When you adjusted the microphone while talking, and other hangup,
> your program automagically switch back to stereout.state display
> -> no ability to save the adjusted gsmhandset.state (the state file
> while talking)

Correct. I'm not sure that I can fix that easily, 

> We should be able to switch between states, and adjust/save them
>  invidually. Also you should display which one is active currently (bold
>  text, or something similar).

Pick the state from a dropdown list? I think that at the moment you get a 
blank screen if the state isn't recognised.

> However I like your program! Keep it up!

Thanks.

> Would be nice to create a googlecode project for this.

But then I'd need a google account :-( 

On Friday 02 October 2009, Laszlo KREKACS wrote:
> On Fri, Oct 2, 2009 at 2:37 PM, Laszlo KREKACS
> 
> <laszlo.krekacs.list at gmail.com> wrote:
> > So when saving there is some dbus messaging going on.
> > But there is no message what is really going on.
> 
> Ok, after looking at the code (line 790):
>    def SaveState(self, arg, scenario):
>         self.audio_iface.StoreScenario(scenario)
> 
> I didnt find StoreScenario on the docs.freesmartphone.org:
> http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesmar
> tphone.Device.Audio.html;hb=HEAD
> 
> Nice to see, there is such an option. I was completely unaware of this
>  feature. Btw, where should inform myself of the correct freesmartphone
>  doc? IS there somewhere a newer doc? How do you do it?

mdbus -s sometimes finds tings that haven't reached the documentation yet. I 
decided to use it instead of the hardcoded paths Angus had.

> For you code: You dont do any sanity checking if the storing was
> successful (what frameworkd returns by the way? True/False?)
> 
> Would be nice to check for it and display to the user about the outcome.

Checking returns and adding exception handling are on the todo list as always. 
I'm guilty of cutting a few corners to see if the lookup table idea would 
work.

On Friday 02 October 2009, Laszlo KREKACS wrote:
> On Fri, Oct 2, 2009 at 2:42 PM, Laszlo KREKACS
> 
> <laszlo.krekacs.list at gmail.com> wrote:
> > ps: Ok I stop spamming your thread.
> 
> Cant stand it...:(
> 
> After I adjusted the mic volume during call, and pushed multiple times
> the save button.
> We hanged up. AFter about half hour, I got a call, and nobody heared
> anything (nor me, nor the callee).

Sorry. This is why I suggested backing up scenarios before using it.

> Im examining the difference between the two state files right now:
> Original: http://paste.pocoo.org/show/142502/
> Broken: http://paste.pocoo.org/show/142501/
> Diff: http://paste.pocoo.org/compare/142502/142501/

Which two state files? If that's a before/after for gsmhandset.state then 
something odd is happening as it has changes in things I shouldn't be 
touching. I guess either I'm saving to the wrong scenario name or this fso 
method isn't working properly yet. Did you save any other scenario between the 
calls? I suppose saving just before the end of the call might let fso change 
the scenario due before processing the save request. 

> Also on the console I have seen:
> Gain effectively muted. Returning 0

That may be an instance of getting 0 for a control that is actually at another 
setting. Unless you move the slider the setting will remain at its real value.

> The Earpiece slider is at 0 (it was always at 0, and worked fine). If
> I raise it, there is no
> difference.
> I see this in the console:
> Speaker: 0 set to 92
> Speaker: 1 set to 92
> Bypass: 0 set to 71
> Bypass: 1 set to 71
> Speaker: 0 set to 94
> Speaker: 1 set to 94
> Bypass: 0 set to 100
> Bypass: 1 set to 100
> 
> 
> Do you have any idea whats wrong?

The diff shows changes to the switch states for several amps and lines in/out 
which I shouldn't be touching. This may have turned off the connections to the 
gsm, in which case moving the sliders won't help.

On Friday 02 October 2009, Laszlo KREKACS wrote:
> On Fri, Oct 2, 2009 at 4:17 PM, Laszlo KREKACS
> 
> <laszlo.krekacs.list at gmail.com> wrote:
> > But there is so many things what changed, that Im completely lost.
> 
> Just wanted to notice you, that restoring the original
> gsmhandset.state file (and rebooting)
> does solve my problem. Im able to take call, and hear the other party.
> (and he able to hear me).

Rebooting?! Was that necessary, or did you just do it anyway? 

> Although your program was nice. It changed the mic way better, what I
> had. Other party
> said, its much louder and clearer.

Great! That's what I was hoping for! Now if I can just get it to save 
reliably...

> Hope you can sort out, why the broken .state file is broken. And where
> the bugs comes from ...



More information about the community mailing list