On Sun, Jul 25, 2010 at 03:21:22PM -0400, Paul Davis wrote: For the meters I'd expect this to be relative to 'digital full scale'. Gains are just dB<nothing> whith 0 dB defined by whatever makes sense for the particular HW. Ciao, -- FA There are three of them, and Alleline.

On 26 July 2010 00:16, Niels Mayer &lt;nielsmayer(a)gmail.com&gt; wrote: Yes, used the default ./configure. Gtk version is 2.20.1. The levels start off looking as they should, but appear to accumulate until peaked out after a couple of seconds. This is when it gets sluggish - switching tabs will take a second at minimum. Hitting the reset peaks buttons resets the levels but they immediately peak again (ie the accumulation stays). After stopping the audio playing (sox play on command line) the peaks take a couple of seconds to drop, and CPU usages falls back to relatively normal levels. Negligible.

On Sun, Jul 25, 2010 at 3:23 PM, &lt;fons(a)kokkinizita.net&gt; wrote: I originally talked about doing this in a previous thread, along with various other things that ended up being impossible, like integrating jkmeter :-). I figured there's enough changes in this first round that need testing&feedback and decided for "release early and often" rather than implementing yet another feature... This sounds like an incremental feature for 1.1 once the other changes I've made are vetted/tested and working. Note that the original meters essentially used the same value-to-pixel mapping for the peak meters -- they just didn't tell you that half-scale was -6dB. This is a side effect of routines I added to draw markings in the scale widgets. GTK automatically auto-detents at the markings -- it's certainly not what I wanted. (See volume.c: e.g. draw_24bit_attenuator_scale_markings(), draw_dac_scale_markings() & draw_dac_scale_markings() called out of envy24control.c:create_analog_volume()). If anybody knows how to get gtk_scale_add_mark() to not setup the "detent" then I could make this an option. (or at least weaken the level of hysteresis)... Otherwise, it's either detent, or no markings. As workaround, and perhaps a better choice for the finer control offered -- use the up-arrow and down-arrow, as well as page-up and page-down keys to move the selected slider. I've found that for the 24 bit attenuators feeding the digital mixer, the 1.5dB step-size pretty much necessitates using up/down arrow to get the right level of control. Alas, this aspect is unchanged from the 0.6.0 version of envy24control. Due to the 1.5db step-size at the top end, It would make a logarithmic control of these inputs quite "jumpy"... Hmm... what 4dBu button?? Sounds like you have a delta1010? Could you send me a screenshot of what that ends up looking like? It is supposed to look like this http://nielsmayer.com/envy24control/Screenshot-Envy24Control-AnalogVolume.p… Yep, I saw code-paths I'd never invoke with my hardware, which is why I wanted to see testing on devices like the M-Audio Delta 1010 and 1010lt. Do you mean on the digital mixer inputs in "Monitor PCM Outs" and "Monitor Inputs" -- those were already stereo paired to begin with. I don't like it that much, but it would have been a big change. http://sourceforge.net/projects/kenvy24/ uses a "Pan" knob on each channel, which makes more sense, and wastes less space. (Alas kenvy24 doesn't work correctly, and appears long neglected). Or do you mean the L/R alternating labels on the sliders? For the "Monitor PCM Outs" and "Monitor Inputs" panels, I did it that way to reduce redundancy. Lots of repeated scale markings wasting screen real-estate. For the "Analog Volumes" I did it out of habit -- one of these days I'll expand my horizons to ambisonics. I guess this should be an option. To be really unixy, I should just have it be something really geeky like "--meter_channel_modulus" and if you set it to 2 you get the existing behavior. :-) Seriously, I guess the stereo pairing should be a binary command-line option in a future version. Thank you for your feedback. Oh, by the way, are you also seeing the high CPU usage issue that others have reported, or is it doing as intended -- which is acutally much lower CPU usage than the stock ALSA /usr/bin/envy24control . -- Niels http://nielsmayer.com

On Mon, Jul 26, 2010 at 1:50 AM, &lt;fons(a)kokkinizita.net&gt; wrote: Yes, but orthogonal to getting what I'd already completed out... And also, I figured there'd be discussion about the confusion in scales on "Monitor Inputs" and "Monitor PCM" panels, such as: This is a confusing aspect of adding a scale to the existing GUI panels for the mixer -- the scale-legend, organized in L/R pairs as far away as possible from the meter, which does not share the same scaling, nor logarithmic shape. These legends are for the 0 to -144dB 24 bit attenuator feeding each input of the digital summing of the ice1712's digital mixer. See http://nielsmayer.com/envy24control/envy24mixer-architecture.png . The 0.00 to -48.1 dBFS readout value from the peak meter is displayed centered under each meter for each input channel. Underneath, to the left and right, are the readouts for the L/R attenuation into the ice1712's digital mixer. The peak readout in dB centered under each meter follows the peak-levels in the meters. When they read "OdBFS" in red, you'll see the peak meter red at the top, and when they're at "-2.00" you'll see a different colored line indicating the peak.... That is supposed to given an indication of the "scale" which was implicit/hidden and somewhat misleading in the 0.6.0 version's meters -- since they too were linear, and only could represent 256 levels offered by the hardware peak metering. The difference now is different meters, which should significantly lower X resource usage, as well as maintaining and displaying a peak-level for ~20 channels of audio. If I could have started from a blank slate, it would have been completely different. On the digital mixer, I'd put them all in one panel and save a slider-per-channel, replacing it with a pan-pot, like http://sourceforge.net/projects/kenvy24/ . I'd also have chosen Qt because I'm just trendy like that. If someone has a solution for this, let me know. Otherwise I will add it to the list of things to look into. Thanks. That was helpful. Hmmm, you could pack some 32 channels of audio into a single computer with 4 EWS88MT's, eh? Does the interconnect cable that it has for digital syncing between cards internally work in linux as well? I'll either do that, or make "--stereo" an option for grouping in "Analog Volume" (note that the L/R groupings in the "monitor PCM" and "monitor input" panels will still exist since they feed a stereo mixer). And then another option "--noscale" to get rid of the scale markings/detent on the sliders (leaving the dB peak level readouts and slider level dB readouts). --------------------------- ALSO:: A response I forgot to send regarding some of your previous comments: On Fri, Jul 16, 2010 at 4:16 PM, &lt;fons(a)kokkinizita.net&gt; wrote: I was thinking of a scenario where the final mix out of the mixer could have it's levels (optionally) dithered for the final output to 24, and where the "least-amplitude-point" and "maximum amplitude point" of the 36 bit final mix signal could be linearly mapped to the output 24. I guess this means you're splitting the difference on whose losing the bits -- so that the parts mixed quieter don't lose more resolution than their louder, peak-setting, counterparts. Another way to describe it is instead of turning down the input gains to prevent output clipping (which sort of compromises your mix as you may need to start re-levelling every input), you can have the input levels be that of their desired position in the mix, and then use a linear mapping to convert that maximum to the 24bit maximum point, mapping&scaling all other values "below" it into that 24 bit range. I guess this would most easily be accomplished in floating-point -- although that wouldn't give direct control over where the bit loss occurs. Do hardware mixers exist that work like "floating point" in a DAW with "unlimited" ability to sum without clipping, while not losing or fuzzing any bits going into and out of floating-point? (Obviously, they can't be unlimited w/ a finite bit width, but 64 bits of integer is certainly enough to represent a lot of summed HD channels). Another way to look at this mixing conundrum: Should the kick-drum with mostly bass-components get more bits than the trail-off sizzle on the high-hat, or the the reflections of the attack off the room? It's certainly not the way human hearing perceives loudnesses, so it's probably not the most ultimate means of faithful audio reproduction. On the other hand, why not just use a 64 bit digital mixer/summing and output a 64bit "frame" from the digital mixer via PCI bus, and then do whatever bus-compression or other mappings, both linear- and non- in the computer, in software.). Who makes that chip? Please note I wasn't arriving at that conclusion on the whole set of cards that use this soundchip. Only w/r/t its internal digital mixer which is often not the way these cards are used normally anyways. Therefore my comment related only to the "Monitor PCMs" and "Monitor Inputs" part of the envy24control. That mixer doesn't give you control over dithering and appears to just give straight truncation as an option. And for all intents and purposes, whether this bit is dithered is pretty irrelevant. Of course if you record the 24 bits out of the digital mixer, and then master for CD/internet by dithering to 16, then you probably get the use-case this chipset sought to solve. However, the digital mixer part of the card, apart from headphone "zero latency monitoring" of inputs, isn't isn't what you'd use through jack, you'd use the "system" inputs and outputs directly. And those would be mixed using whatever form of mixing bus used by the DAW, e.g. floating point or 64 bit integers or ... What I need to investigate is whether perhaps I prefer the sound of truncation :-) -- I have the occasional feeling that the sound of mixing in the envy24's digital mixer is "clearer" than through the soundcard->alsa->jack->app->jack->alsa->soundcard route. I need to try out "Dither: none" in qjackctl next time just to make the comparison fair, given that I now know what is happening in the envy24 digital mixer and better understand where the sliders in http://nielsmayer.com/npm/Screenshot-Efficient-Meters-Envy24Control.png map to in http://nielsmayer.com/npm/envy24mixer-architecture.png (and that the "96" marking is truly incorrect, it should be "-144dB" per the architecture diagram...) -- Niels http://nielsmayer.com

On Tue, Jul 27, 2010 at 04:08:11PM -0400, Tim E. Real wrote: Again, I can't imagine that GTK would be so braindead as to not allow tick marks without these silly 'detents'. Real detents require force feedback. A mouse doesn't provide that. This GTK thing is completely broken. Ciao, -- FA There are three of them, and Alleline.

2010/7/28 Jörn Nettingsmeier &lt;nettings(a)folkwang-hochschule.de&gt;de>: Something like that, probably. This seems interesting: http://www.youtube.com/watch?v=jXITjLurof0 But I won't believe that it works as well as they claim until I've tried it with my own fingertips... Dominic

Back in 1989, rockstar-turned-computer-geek http://en.wikipedia.org/wiki/Todd_Rundgren gave a speech at Xerox PARC entitled "Musings on the Bronze Age of Computing"... speaking on the http://en.wikipedia.org/w/index.php?title=Data_glove and the possibility of sensory feedback: .... "If anyone ever invented a dataglove with sensory feedback on just one finger, you know the first place that glove goes wouldn't be on their hand!" Niels http://nielsmayer.com

On Tue, Jul 27, 2010 at 3:56 PM, Tim E. Real &lt;termtech(a)rogers.com&gt; wrote: Tim -- thanks for playing Gtk-whackamole with the markers and scale widgets. It became quite annoying. I began to wonder if I shouldn't be spending time getting "kenvy24" working instead. :-) I am incorporating your earlier suggestions into the code. Looking forward to what you come up with on the scale gain/attenuation values. I personally don't find the current behavior offensive, although the detenting should be optional... and actually prefer the keyboard up/down and page/up-down control better. Also the midi control shouldn't be bothered by the detents: -m, --midichannel midi channel number for controller control -M, --midienhanced Use an enhanced mapping from midi controller to db slider (note the latter using a db lookup table that's in midi.c, i believe) Then you can use whatever slider implementation you prefer, but, alas , not for the things you might want to control. Also https://bugzilla.gnome.org/show_bug.cgi?id=565656 is the original patch for the scale widgetry. Matthias Clasen [reporter] [gtk+ developer] 2008-12-25 23:34:28 UTC ............... Sometimes it is useful to point out certain values in a scale, and make it easy for the user to select them exactly. See e.g bug 565144 ( https://bugzilla.gnome.org/show_bug.cgi?id=565144 ) where a scale is used for fade control between left and right, and midpoint would be very beneficial. Another use case would be to mark the 0dB position on a volume slider. Here is a patch that adds this feature to GtkScale. It allows to place "marks" on either side of the scale, optionally with text or icons. Behaviour-wise, selecting the mark values is made easier by adding a little resistance while dragging the slider with the mouse, and making keynav go exactly to the mark value instead of stepping over it. .............. Actually, I'm not sure whether this is Gtk-whackamole, or groundhog day :-) If they'd just fill their divets there'd be no detents for the slider to get stuck on. Niels http://nielsmayer.com

On July 27, 2010 09:09:51 pm Tim E. Real wrote: Follow-up: Close but no cigar. There are oh-so-subtle problems with each label's top and bottom stretching. Even with extra 'gtk_alignment' widgets on top and bottom, I couldn't seem to perfect it. So I think the best solution now is let the application custom draw the marks in a blank window beside the sliders. Bonus: We can fit as many markings as we want, and draw them any way we want to! It's just all pure graphics drawing now. I think this is probably what one would have to do with most other brands of slider widgets anyway. The key is to pay attention to the half-way point of the thumb track size, which is available, and carefully draw the top and bottom marks with that in mind, as well as the other marks. Thus allowing for different themes and styles. I'll try to give it a go. PS: About making the current markings optional: If possible if you have time, try to make the option 'live' with a button so users can rapidly switch it on and off. That would be most awesome. When you need it, click, and there it is. Tim.

Hey gang. Took a break for a few days... On July 28, 2010 09:10:32 pm Tim E. Real wrote: Talk about whack-a-mole, gtk 2.20 has functions to determine those exact spaces. However I don't have 2.20 on my one-year-old distro. So I feel they're too new to use always, but I can put some #ifdef 's in there to take advantage of them if available. Yes, of course, that was easy. In envy24control.c connect all of the vscale slider objects to a single key handler: // Let us handle the page up/down snapping. gtk_signal_connect(GTK_OBJECT(vscale), "key-press-event", GTK_SIGNAL_FUNC(slider_key_handler), 0 ); The slider_key_handler() does all the rest of the work. In the handler, gtk passes you the object which called it. Perfect. Unlike QT, which sort of frowns upon that ("breaks modularity") and requires you to ask what the object was. I've got my handler done. Works just fine. That is, I've got slider page up/down snaps, with no markers needed! Just one problem: For the ADC sliders, the top dB value is +18.5dB. Therefore if we just 'blindly' move the slider 12 steps to the next 6dB positions, we get +12.5, +6.5, +0.5 dB etc. That '.5' offset, all the way up and down the scale, is not good. So my next step is to use the ALSA dB functions (_ask_dB) to 'ask' what the corresponding integer values are for +18.0, +12.0, +6.0, +0.0 etc. and these will then be the correct positions to set our page stops. I'm pretty sure, if I can finish this, it will be all you (we) wanted originally, and more. Niels do you have a new release or repo I can work with rather than the original release, which may be too outdated to patch against by now? Thanks. Tim.

On Sat, Jul 31, 2010 at 11:24:31PM -0700, Niels Mayer wrote: No, it's one switch for all channels. The original has the same problem. Don't waste your time with it unless someone else thinks it matters. As said I have fixed levels on all channels, I don't ever use the mixer (as the card is connected to a real mixer anyway), and everything is initialised by an alsactl restore on booting. So in practice I never use envy24control. Apart from that, I just don't understand why I toolkit like GTK apparently makes it difficult to get such a simple thing right. Same for the faders. Ciao, -- FA There are three of them, and Alleline.

FYI, I added the following since http://nielsmayer.com/envy24control/mudita24-1.0.1.tar.gz ... shall I release a 1.0.2 with the following additions (?): * fixed --card and --device to allow valid ALSA names and numbers ( https://bugzilla.redhat.com/show_bug.cgi?id=602900 ). * Add display of "Delta IEC958 Input Status" under "Hardware Settings." * Updated and corrected manual page and README Before I release, I'd like to know what happens on cards that don't have this feature, or if it's universally supported, but badly named. Can those with a Terratec or other card test the following command and let me know the results of command "amixer -c M66 cget iface=MIXER,name='Delta IEC958 Input Status'" e.g.: ................................................................................................. Also, in case anybody ever wondered what this one, under "Analog Volume" is for: "Volume Control Rate Register" I added it to the README: ......................... Notes on the Envy24's hardware Digital Mixer and hardware Metering, by Niels Mayer ( http://nielsmayer.com ): -------------------- The "Monitor Inputs" and "Monitor PCMs" tabs contain multiple scale widgets grouped into L/R pairs and an associated peak-level meter. Each scale widget represents the 24 bit attenuation value of each input to the ice1712-based soundcard's digital mixer. This mixer is typically used for zero-latency monitoring of "live" inputs, alongside backing sounds and effects coming from the eight channels of PCM feeding the digital mixer. When many inputs are "hot" simultaneously these scale-widgets attenuate the inputs going into the digital mixer to prevent the output from clipping. For details see http://nielsmayer.com/npm/envy24mixer-architecture.png (from http://alsa.cybermirror.org/manuals/icensemble/envy24.pdf ) This is what the above manual says about the Envy24's digital mixer: Adjustment of responsivity vs. "zipper noise" from the 1.5dB steps at the top-range of the digital mixer attenuators is achieved by the following control under "Hardware Settings": The peak metering data is displayed as 0 to -48dBFS in envy24control's meters. This data is derived from the envy24's hardware peak metering: This resolution of the hardware metering is descibed by Fons Adriaensen in a mailing list discussion: http://lists.linuxaudio.org/pipermail/linux-audio-dev/2010-August/029009.ht… Note that hardware metering data is also available from the command-line: .................................................................... Niels http://nielsmayer.com

On Wed, Aug 4, 2010 at 12:00 PM, Tim E. Real &lt;termtech(a)rogers.com&gt; wrote: Yep. Truncated. At least for my purposes, the original faders w/ 144dB dynamic range and linear mapping on the controls made the "business end" of the gain -- the top 20-30dB -- occur over far to few pixels to be controllable via mouse. At the same time the meters themselves go down to -48dB and there is the whole confusion about the scale-markings on the analog sliders versus the meters. Now there's none. And the "top end" of the slider is now more easily controllable by mouse. The MIDI control and other more fine-grained control (e.g. via , e.g. alsamixer-qt4, alsamixer, or other programs) is not affected. In this new 'mudita24' interface, the input is set "off" when then digital mixer input attenuator is moved below -48dB, but not via MIDI or other external control. Therefore if someone actually needs to mix an input at -48dB or lower, they can still use the MIDI controllers or a different mixer like alsamixer-qt4 to set those kind of levels. This seemed like a better compromise than wasting more than half the slider real-estate to changes that can't even be heard (unless you've got the volume turned way up). If this is particularly bothersome please let me know and I guess I'll add an option to give the full 0 to -144dB range back. However, if you're doing that kind of mixing, perhaps using a different mixer than the envy24's hardware mixer is more appropriate? Yes, I see that this is very skin dependent and what is working for me isn't working for others. (Could you send a picture to show me what the coloration of your meters ends up like on your system?) Any suggestions on using a different built-in color so as to not worry about contrast or visibility issues? Is there a known standard gnone name that can be applied to the foreground color? Alternately, how about options --meterfg and ---meterbg that allow you to specify the colors? I'll have to look into this one... seems like a 1.0.2 is inevitable... ----- We're all looking forward to these improvements. I think it makes sense to update the minimum to gtk+-2.0 .. I'm not sure what the ALSA folk think. Also my use of gtk_label_set_markup() is another one of these newer functions. -- Niels. http://nielsmayer.com

On July 25, 2010 06:57:42 pm Tim E. Real wrote: Er, sorry scratch that. Again, you are right, they should match what ALSA calls them. And "... locking" is still better than "locked". So I say instead some descriptive tooltips would be very handy for users, at least on the hardware settings tab, even if there is a manual. But what about language translations? Is that more or less automatic, or requires intervention? You'd have a good advantage over other mixers there with real descriptions. Tim.

On July 26, 2010 03:35:43 pm you wrote: Yeah, don't worry too much about it. After all, it was my own fault about that lock control for not 'knowing my card', and I overreacted a bit. Plus, anyone with one of these cards is likely to have bought it themselves and/or have a manual, as I do. So tooltips may be nice but unnecessary here. And tooltips would not have clued me into why I had no Flash audio, he he... I'm following these other posts. Interesting variations. Nice to know my card is good. Tim.

On July 25, 2010 08:00:23 pm you wrote: Oops, don't know where that 20% came from. Something must have been running. Both mixers consume nothing until woken up, and then as a silly test I operated the sliders, original consumes ~30% new one ~50%, but of course that's probably just because they do a bit more work now when operated. When I provide some input and watch the meters, still no CPU consumption. Is there some test you want me to do? It's a 32 bit system, btw. Did some coding... Yep, gtk_scale sure is rather unforgiving in its spread. It is the number of marks causing this. We ask it for fifteen ADC slider markings, and it does this ? I even tried xx-small font size (which still looks good), but no change. And I tried removing the texts, leaving just the ticks. No change. Niels, please do the following (sorry I don't have a patch for you), trust me it will look great at the expense of only 28 extra pixels for the minimum height over the original - it's all you can really do, man: Remove the -72 and -108 dB marks on all the monitor sliders in volume.c: draw_24bit_attenuator_scale_markings(). Remove the -42 and -54 dB marks from the DAC sliders in volume.c: draw_dac_scale_markings(). Remove the -18, -30, -42, -54, -60 dB markings from the ADC sliders in volume.c:draw_adc_scale_markings(). Change the level meter heights by changing gtk_widget_set_usize(drawing, 24, (60 * tall_equal_mixer_ht + 204)); to gtk_widget_set_usize(drawing, 24, (60 * tall_equal_mixer_ht + 168)); in envy24control.c: create_mixer_frame(). Trust me they'll love it ! I just noticed that the upper red part of all the meters are gone. Any plans to re-instate that red coloured portion? I fear a backlash on that. IIRC I observed behaviour you described about the last slider marks requiring no text. Seemed that if you give the last mark text, it goes ahead and puts a blank one at the end? Not sure. I did not take a look at the slider 'hysteresis' problem though, sorry. Have great day and a better tomorrow. Tim.

On Mon, Jul 26, 2010 at 12:29 AM, Tim E. Real &lt;termtech(a)rogers.com&gt; wrote: Thanks! Yes, it does look better. I've applied these suggestions to my current sources and they'll be part of an upcoming release that addresses the issues... If you have any suggestions on getting rid of the annoying detent/hysteresis as you move the sliders past the markings, that would be great. -- Niels. http://nielsmayer.com

On Mon, Jul 26, 2010 at 10:25 PM, Tim E. Real &lt;termtech(a)rogers.com&gt; wrote: No patch needed... I've made the suggested change and it works identically. I still need to make a similar change in mixer_volume_to_db() and get the value of my MAX_MIXER_ATTENUATION_DB constant out of ALSA , even though this is an unchanging aspect across all ICE1712 chips per architecture: http://nielsmayer.com/envy24control/envy24mixer-architecture.png #define MAX_MIXER_ATTENUATION_DB 144.0 /* for -144dB */ #define MIN_MIXER_ATTENUATION_DB 0.0 /* for 0dB */ /* NPM: the control values for the digital mixer are 0-96 and not the dB attenuation values of MAX_MIXER_ATTENUATION_DB/MIN_MIXER_ATTENUATION_DB The following values comprise all the signals mixed in the ice1712's digital mixer: MULTI_PLAYBACK_VOLUME, HW_MULTI_CAPTURE_VOLUME, IEC958_MULTI_CAPTURE_VOLUME: numid=11,iface=MIXER,name='Multi Playback Volume' ; type=INTEGER,access=rw---R--,values=2,min=0,max=96,step=0 : values=78,67 | dBscale-min=-144.00dB,step=1.50dB,mute=0 numid=27,iface=MIXER,name='H/W Multi Capture Volume' ; type=INTEGER,access=rw---R--,values=2,min=0,max=96,step=0 : values=0,0 | dBscale-min=-144.00dB,step=1.50dB,mute=0 numid=31,iface=MIXER,name='IEC958 Multi Capture Volume' ; type=INTEGER,access=rw------,values=2,min=0,max=96,step=0 : values=16,0 */ -- Niels http://nielsmayer.com

On Mon, Jul 26, 2010 at 1:47 AM, Takashi Iwai &lt;tiwai(a)suse.de&gt; wrote: Takashi -- I am glad to hear of your interest and thankful for your consideration. It appears that some of the code-review and testing is already happening in linux-audio-dev ( http://linuxaudio.org/mailarchive/lad/2010/7/25/172231 ) so I will submit a more final patch to alsa-devel, once some issues found in testing&usability get resolved. Now that I understand the correct way to submit ALSA patches, I will follow instructions from http://www.alsa-project.org/main/index.php/GIT_Server#Occasional_Developers for my final ALSA submission. In my defense of being presumptuous to change the version number, please note that the submitted patch didn't include the autoconf change that sets the new version number ( http://nielsmayer.com/envy24control/envy24control-0.6-to-1.0.patch ). The "1.0.0" is in 'configure' for the source distribution ( http://nielsmayer.com/envy24control/envy24control-1.0.tar.gz ) to help distinguish it from the standard version.... To avoid confusion for the next 1.0.1 release, I'll do something similar, but I'll change 'configure' in the source distribution to build "mudita24 1.0.1" rather than "envy24control 1.0.1", using the same sources. And release as "mudita24-1.0.1" ... Then I'll submit the final sourcecode to alsa-devel as [PATCH] results, minus the config/naming changes. I hope this is an acceptable solution. Thanks, Niels http://nielsmayer.com

On Mon, 2010-07-26 at 12:13 +0200, I wrote: Pardon. CPU usage when playing and moving the DAC faders for 0.6.0 it's > 20% < 25%, but for 1.0.0 it's > 30% < 50%. I did watch the complete CPU usage first, but the application's CPU usage. I did the same mistake when I watched the meters, but regarding to the faders the information seems to be important.

On Mon, 2010-07-26 at 11:52 +0100, James Morris wrote: Yes, after changing the values there isn't a Gtk-WARNING anymore :).