Hi again, first of all, let me put this clear: I'm no kmix maintainer nor a usual kmix developer. I'm only writing this backend, because the kmix devs refused to support OSS4 (because they think there is no need for it, yet). However, I did take a close look on the kmix source and it's API.
Clive is right here, kmix accesses both ALSA and OSSv3 with its native API. However, the design principles indicate, that it's mainly designed for ALSA, e.g. the classifications input/output/switches are hardcored. This should be possible to change easily though. I think, for now, I'll leave it the way I currently did it, although it has some dirty hacks (which will be reworked to behave transparently) - until the MIXF_MAINVOL etc. flags are set properly for all drivers. I'll soon release the source of the backend (GPL enforces this, otherwise I would keep it internal), but with the comment to not use it as a template for another mixer and that it's design is temporary. As Hannu may remember, I'm also a distributor and a new release is close to completition - kmix must work at least basically until then, that's why I'm running out of time a bit. > It appears that Apriori is not content with using OSS_v4 reduced mixer > API which is understandable as a large proportion of the drivers do not > express any mixer controls at all when limited to this API. Yes, of course.. I can't develop and distribute software thats meant to support something, but in fact only supports a tiny portion of it. I intended to push the patches needed upstream to the kmix devs - well, this will have to wait then. Btw... I asked the HAL devs to support oss4 - the request was silently ignored. http://lists.freedesktop.org/archives/hal/2008-February/010777.html KDE4's main soundhardware detection completely relies on HAL. It's unfortunately impossible for us at yoper to fix all these shortcomings alone, maybe an "offical request" by oss devs could help there. Best regards > Hannu Savolainen wrote: > > Clive Wright wrote: > >> [EMAIL PROTECTED] wrote: > >>> Hi again, > >>> > >>> the biggest problem with kmix is that it doesn't even has the > >>> possibility to form a tree layout. If it could, the dicussion here > >>> wouldn't go so long :P > >> > >> I am left wondering what would be the easiest solution to provide an > >> OSS_v4 mixer for KDE > >> > >> The initial idea of modifying kmix would appear to be the simplest > >> solution but on closer inspection the amount of work involved in > >> providing a fully functional mixer and the problems that need to be > >> overcome could make another solution more attractive. > >> > >> A KDE version of ossxmix. Perhaps called kossxmix or kossmix, > >> based on the structure of ossxmix but dcop aware and using the qt > >> toolkit instead of gtk. > > > > I have rather limited knowledge of KDE (as well as Gnome). So maybe you > > could explain what kind of requirements KDE has for a mixer program. For > > example does KDE have some kind of audio mixer/volume control mechanism > > you need to support? > > > > I think that a KDE specific mixer should use approach that is rather > > similar to existing KDE mixer for ALSA. Instead of input/output/switch > > sections you need to use main/pcm/rec/monitor. In addition to volume > > sliders there can also be onoff/mute/enum controls. You don't need to > > care about the tree tructure. > > > > Fully featured mixers like ossxmix don't typically sit as an icon in the > > tool bar. So I don't see there any benefit in implementing any KDE > > specific version of it. > > > > Actually the the most ideal OSS mixer would be one that is implemented > > on top of plain X11 (Xlib). Using GTK+ causes all kind of library > > version problems and consumes too much space/memory in embedded > > environments. > > My knowledge of KDE is also somewhat limited as my desktop of choice is > Gnome. Perhaps Yair would care to comment on this as I know he is a KDE > user. As I understand it kmix is a standalone mixer which accesses the > sound systems (currently Alsa and OSS_v3) using their native API so > adding a subset of OSS_v4 should be relatively simple. The only thing > that makes KDE applications special is their look and feel which would > require them to use the same Qt toolkit and to support Desktop > COmmunications Protocol (DCOP) for integration into the KDE desktop. > > > Gnome presents a totally different problem in that GTK applications > already match the look and feel of Gnome. The Gnome volume control is a > Gstreamer application that relies on Gstreamer libraries to translate > its own API to that of the sound system in use. I had considered > providing a full translation of OSS_v4 reduced API to that of Gstreamer. > Indeed I already have it on my computer as a work in progress but it has > become apparent to me that limiting the Gnome volume control to one > simple slider that to all intent and purposes controls the master volume > (in reality it is vmix's volume control) provides the best solution > for a non-technical user who expects to be able to control the master > volume using the keyboard or mouse without any setting up. Other > controls being accessed using ossxmix which is launched in response to > double clicking the Gnome volume applet's icon. > > Kind regards, > Clive > > _______________________________________________ > oss-devel mailing list > oss-devel@mailman.opensound.com > http://mailman.opensound.com/mailman/listinfo/oss-devel _______________________________________________ oss-devel mailing list oss-devel@mailman.opensound.com http://mailman.opensound.com/mailman/listinfo/oss-devel
