<uvos__>
you could add support for a special value here "default" that makes the applet query pa for the default sink and use that
<rafael2k_>
but it is ok it does not work?
<rafael2k_>
volume just does not change
<rafael2k_>
if it changed the default I would be happy
<uvos__>
rafael2k_: yes because the stream it changes is set in that config file
<uvos__>
and that stream only exists on mapphones
<uvos__>
moveing that config file into leste-config is one option, but just asking pa what the correct stream is is better (since it gets that from ucm)
<uvos__>
however support for the config file must remain
<uvos__>
since pa might not allways know in voice call mode
<uvos__>
depending on how the device implements voice calls
<rafael2k_>
I think using default would be fine as a start, no?
<rafael2k_>
(or add some setup to a pinephone specific config?)
<rafael2k_>
I don't really get it
<uvos__>
change should be: query pa for the default sink if the key it checks on the line linked above dosent exist
<rafael2k_>
right
<uvos__>
you can check the sphone pa module on how to query pa for defaults
<rafael2k_>
tks
rafael2k__ has joined #maemo-leste
<Wizzup>
we need to make the volume applet better in any case
rafael2k_ has quit [Ping timeout: 256 seconds]
rafael2k__ is now known as rafael2k
<Wizzup>
we need separate streams for speaker, headphone, bt sets, in call audio (speaker), in call audio (hp/earpiece)
<Wizzup>
s/streams/volumes/
k1r1t0 has quit [Read error: Connection reset by peer]
k1r1t0 has joined #maemo-leste
inky_ has joined #maemo-leste
inky has quit [Ping timeout: 272 seconds]
<Wizzup>
uvos__: any suggestions for a partition to install leste on, on the tablets?
<uvos__>
not really
<uvos__>
you can user userdata but that breaks android
<uvos__>
or you can use emtstorage
<uvos__>
but then android breaks mainline by trying to format it fat
<uvos__>
either way it sucks
<uvos__>
all other partitons are to small really
<Wizzup>
ok, so I'd have to override android install then
<uvos__>
yeah and im not even sure you can flash to any of these
<uvos__>
i dimmly remember flashing linux to some small 200mb partition
<uvos__>
to then have it shuffle itself over to emtstorage
<uvos__>
either way its painfull
<Wizzup>
so which partition do we need to keep?
<uvos__>
well mbm and mbmloader for one xD
<uvos__>
i think the partion i used initally was cdrom
<uvos__>
since ucm tels pa how manny steps there are
<uvos__>
and it translates this into a 0-1 float
<uvos__>
so the applet dosent have to care about this at all
<freemangordon>
so it is in UCM?
<uvos__>
(i remove it)
<freemangordon>
so, we have 5 steps while in call and 20 otherwise(for example)?
xmn has joined #maemo-leste
<freemangordon>
uvos__: ^^^ ?
<uvos__>
yes - no, so in ucm you can set how manny steps there are
<uvos__>
but this affects alsa only
<uvos__>
pa just gives 0-1 range
<uvos__>
and rounds to the nearest alsa step
<uvos__>
but if you want that behavior you only need to have the applet set 0.2 0.4 etc
<uvos__>
when in call
<freemangordon>
and how do you control that?
<freemangordon>
hardcode?
<uvos__>
same way as that code, check what stream your controlling
<uvos__>
the applet allready and still knows if its call audio or not
<freemangordon>
yes, but how does applet know on how many steps to divide that range per particular stream?
<uvos__>
i could check what alsa control pa is using, pa exposes this
<freemangordon>
because the code you removed was getting that info from stream properties
<uvos__>
then it comes from ucm
<freemangordon>
so, if ucm supports custom properties per stream, then we shall restore the removed code in some shape to get it from there
<uvos__>
no
<uvos__>
im pretty sure you can change pas behavior anyhow
<freemangordon>
instead of hardcoding the number of steps per stream
<freemangordon>
ok, if that's the case yes
<uvos__>
pa rounds
<uvos__>
need to check what happens to the volume of the stream
<freemangordon>
but please, do POC and try to make a configuration in which we have to press volume up only 5 times to go from 0 to 100% while in call and 20 times when not
<uvos__>
well chanigng call audio volume dosent work anyhow
<uvos__>
so
<uvos__>
that should work first
<freemangordon>
ugh
<uvos__>
before we deal with this comperatively unimportant detail
<freemangordon>
any idea why?
<uvos__>
yes
<freemangordon>
sure, not something urgent
<uvos__>
pa has no idea there is any audio
<freemangordon>
heh
<uvos__>
so it refuses to change anything
<freemangordon>
passtrough
<uvos__>
since there is nothing to change
<freemangordon>
I guess thats some alsa thing
<uvos__>
its the same thin as allways
thunderysteak has quit [Remote host closed the connection]
<uvos__>
the omap4 has no idea call audio is active on mapphones
<uvos__>
since its not involved
peetah has joined #maemo-leste
thunderysteak has joined #maemo-leste
<freemangordon>
ok
<freemangordon>
but, this is d4 specific, no?
<uvos__>
sure
<uvos__>
and pp
<freemangordon>
ah
<uvos__>
so everywhere call audio works in the first place
<uvos__>
d4 + freinds ofc
<uvos__>
they are alle the same
<freemangordon>
so, do we need some PA module that is aware of USB audio? or?
<uvos__>
there is no usb audio
<freemangordon>
ah
<uvos__>
the audio dosent enter the procesor at all
<freemangordon>
directly from the modem to the earpiece?
<uvos__>
yes
<uvos__>
we need some module that fakes a active stream i gues
<freemangordon>
omg
<freemangordon>
yeah
<freemangordon>
but, we already have kernel modem audio device on d4, no?
<uvos__>
no not really
<freemangordon>
I would say it should take care of that
<uvos__>
not like that
<uvos__>
no idea if fakeing a active stream is ok in alsa
<freemangordon>
ok, I admit this is out of my area of expertise
<uvos__>
the kernel framework is kinda not ready for this
<uvos__>
we have this problem alle the time there
<freemangordon>
maybe we shall ask upstream how to proceed
<uvos__>
it dosent uderstand that its mixer is controlling audio that its not playing or reciveing
<freemangordon>
umm, wait, is that what all HW mixers do?
<freemangordon>
*isn;t
<uvos__>
no
<uvos__>
hw mixers allways have a stream that comes from the kernel somewhere
<freemangordon>
analog mixers I mean
<uvos__>
oh sure, but those old devices dont use asoc
<uvos__>
if you have a classic alsa driver you can just implement random controlls
<freemangordon>
don;t tell me upstream kernel has no support for analog mixer/amplifier
<uvos__>
im not
<freemangordon>
can;t we use that?
<uvos__>
but in the asoc framework no
<uvos__>
we have asoc driver
<uvos__>
:P
<freemangordon>
umm
<freemangordon>
what about another driver?
<uvos__>
sure you can write another driver
<uvos__>
or rather replace the asoc one
<freemangordon>
hmm
<freemangordon>
we have simple amplifier for start
<freemangordon>
it won;t help
<freemangordon>
but, at least might give us a clue how to write a driver that has analog ports only
<freemangordon>
uvos__: what about if we add volume support to simple-audio-amplifier?
<freemangordon>
how is volume actually controlled?
<freemangordon>
AT commands?
<freemangordon>
also, I see no such requirement that asoc component must be digital only
<freemangordon>
see simple-audio-amplifier/simple-audio-mux
<uvos__>
freemangordon: this isent the problem at all
<uvos__>
the mixer is there
<uvos__>
its just linux thinks its not active
<uvos__>
because it is connected to the omap4
<uvos__>
its jsut also connected to something else entirely that might need it
<uvos__>
this is about pm purposes
<uvos__>
and then we have pa
<uvos__>
that only thinks streams are active it it is involved
<uvos__>
it has no concept at all of a stream that isent inside of pa