On August 17, 2010 08:53:46 pm you wrote:
On Tue, Aug 17, 2010 at 3:25 PM, Tim E. Real
<termtech(a)rogers.com> wrote:
Try my patches. See AUTHORS for changes and
TODOs.
Once again set up a fresh mudita24-1.0.3 folder and apply these patches.
So I applied the patches (
http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20100817/
d02f8aaa/attachment.bin ) by doing
'cat mudita24-1.0.3-patches-2/*.diff | patch -p1 --backup' in the
mudita-1.03 directory (
http://nielsmayer.com/envy24control/mudita24-1.0.3.tar.gz ) and it all
looks great and works nicely.
Seems much easier to control and snappier than 1.03, which seemed to
slow things down with the sliders (or the ALSA level callbacks) versus
1.0 version. Now it's back to feeling quick again.
The one regression I'm seeing versus the original 1.03 version: when
you move the sliders up and down in "Monitor Inputs" or "Monitor
PCMs", the dB labels change width going from -X.X to -XX.X (e.g.
"-9.9" to "-10.0" changes width). This width change propagates
through
gtk so that if you do it on the left-most slider, all the other
sliders will jostle-around horizontally as you sweep the attenuator
downwards from +0.0 past -9.99 ... This is not happening on "Analog
Volumes" -- I think I solved this issue in the original code by adding
a space after the last decimal if the value > -10.0.
I found out the GtkScale
"digits" property, which automatically rounds all
values to the chosen number of places, does not work unless the
value readout is enabled. IMO this is broken, it should work always.
Also GtkScale doesn't properly size its own label when the label is at top
or bottom. Text becomes chopped off or spills pixels into a neighbouring
widget.
So, a related TODO I forgot to mention, which would have been the solution
to the above sizing problem (had we used GtkScale's own label),
is this:
We want to grab the width of a worst-case string like +88.88 (I guess simply
by asking pango) before creating all the labels (or after a theme change).
Then, add a single "size-request" handler for all the labels and make sure
they *never* alter from this worst-case width (+ a few border pixels).
That should keep everything fixed in place.
Let me know if you want them in another form,
applied to some later
version or something.
Nope, I've been waiting on your changes and doing other things.
I have not touched the meters or slider ranges
yet.
But I think I have accomplished what I primarily set out to do, which is
have slider markings and make them, and the analog slider min/max,
depend on ALSA, to support different codec chip(s).
*** That is the part which needs testing by all of you with various cards
!
I will test the Terratec DMX6fire next...
Now I'm wondering what happens if the
analog ALSA control names change.
Would different codecs have different control names?
Maybe that's why that card you mentioned before didn't have an analog page?
Was it worth my effort, to ask ALSA for the ranges to set the analog
sliders/markings instead of hard-coding them? Was my assumption that
different codec chips might have different ranges correct? We'll see...
Observe the analog slider markings/stepping and
let me know of any
problems.
One other regression I noted is that with the -n ( --no_scale_mark )
option leaves some extra space in the "Analog Volumes" panel, compared
to the 1.03 version.
Ah, yes, possibly the marker drawing area is not fully
collapsing
with no markers, will check. I forgot to look at this and ensure
it can go to zero width, or else don't create it at all, with no markings...
I also notice that in 1.03, I forgot to add verbiage for the "-g" (
--channel_group_modulus )option to the --help output.
I couldn't figure out a way to make the mouse
wheel snap to the markers,
wheel gives the same scroll type as moving the slider: GTK_SCROLL_JUMP.
Will test that along with the Terratec. Given how coarse the
ADC/DAC/mixer controls are to begin with, is there a way to set the
mouse scroll wheel to always increment/decrement the dB value by its
minimum step-size (e.g. 1.5dB for attenuator, 0.5dB for DAC/ADC)? Last
I checked, mouse-scroll incremented/decremented by two "clicks" --
whereas next/prev keys moved by one "click."
The wheel seems to move by
3dB whereas the keys move it by 1.5dB.
That GTK_SCROLL_JUMP thing stopped me in my tracks.
Hopefully there's a style property or something...
There may well be a few fixes and tweaks later,
but I think this is how
I wanted it to be so far. Hopefully we can now move forward with other
items discussed.
Looks good. I'm pretty happy with the resolution and actual gain
control provided by 0 to -48dB, but if you have something different in
mind, go for it...
Sure, I will try.
> Devels: Note that if we wish to remove some of the marker texts later
> to reduce clutter, please keep the actual marks, as this is now what the
> sliders snap to (unless there are no markings at all, or they're turned
> off, in which case it uses the sliders' own page increment values.)
I may
change this, to always use marks even if they are disabled visually.
I like the current level of granularity.
-- Niels
http://nielsmayer.com
PS: Feature request -- have an "L/R gang" available on sets of inputs
in the ADC/DAC section where the size of the set is the "-g" value,
e.g. 2 by default for stereo. This would allow the option of changing
volumes on all channels of a multichannel setup simultaneously. a "-g
4" would allow, for example two groups of four channels, and a "-g 8"
would allow a single group of eight channels. Like the L/R Gang
control on the mixer, this control would be optionally enabled.
The Windows version
has something similar.
You can set all the levels to a few pre-set industry-standard levels,
or click a button and expose the individual sliders.
Personally, I use one input for "guitars" (guitar or bass) and two
for my synth KB's L/R audio.
When I plug in the bass instead of the guitar, the bass has
a much different level than the guitar.
And some of my KB sounds have very weak volume.
So I do in fact operate the ADC/DAC sliders and watch meters, regularly.
Tim.