If you can figure out what mailing list to send this patch to, I'd recommend sending it there. 

Hello,

thanks for the patch. I have applied it to my local work copy.

I modified kmix-platforms.cpp, as the patch breaks compilation for OSS3 based systems. I am now checking for SOUND_VERSION like this:

#if SOUND_VERSION >= 0x040000
#define OSS4_MIXER
#undef OSS_MIXER
#endif

I don't know whether the "#undef OSS_MIXER" is actually neccesary. If mixer_oss.cpp (OSS3) compiles under OSS4, it isn't strictly neccesary, but probably still safer. In any case, I have put the following lines BEFORE the correspoding lines of OSS_MIXER, so that OSS4 has a higher preference than OSS(3).

+#if defined(OSS4_MIXER)
+    { OSS4_getMixer, OSS4_getDriverName },
+#endif

I'll attach the modified kmix-platforms.cpp. Could somebody please confirm that the changed version is working for OSS4?

   Christian

Created attachment 26277 [details]
Adding OSS4 capabilities to Kmix: Orignal patch (yoper)

Created attachment 26278 [details]
Modified kmix-platforms.cpp patch for the OSS4 patch

The original patch broke compilation on OSS3 based systems. This patch now
detects the version, and #incude's the approriate sourcecode and headers.

SVN commit 835252 by esken:

Add OpenSoundSystem V4 support. This is neccesary for newer soundcards
in combination with disabled ALSA support.
CCBUGS: 166591


 M  +19 -0     kmix-platforms.cpp  
 A             mixer_oss4.cpp   [License: LGPL (v2+) (wrong address)]
 A             mixer_oss4.h   [License: UNKNOWN]


WebSVN link: http://websvn.kde.org/?view=rev&revision=835252

There were some comments on the original thread which seem to have been lost in transit: Most importantly, it should be MLEFT, MRIGHT instead of MLEFTREC and MRIGHTREC, otherwise devices on the "input" tab can't change volume.

-- cesium

Oh, and one other thing:
I suggest adding ( ext.flags & MIXF_MONVOL) test to:
		if ( ext.flags & MIXF_RECVOL || name.find(".in") > -1  )
			{
				isCapture = true;
			}

Since M)XF_MONVOL announces a different type of input device:
http://manuals.opensound.com/developer/MIXF_MONVOL.html

Yair, in case you have modfications, please post a patch. I can then apply it to the KDE3.5 branch.

Created attachment 26294 [details]
Attachment to improve OSSv4 support

OK. This patch implements the following:
  A. Switch LEFTREC->LEFT and RIGHTREC->RIGHT to make sliders in input tab
work.
  B. Place devices with MIXF_MONVOL at input tab as well.
  C. Check version after opening mixer. Refuse to continue if version too low.
  D. Adds "break;" statements in wrapIoctl and ENODEV fail case.
  E. Some improvements to classifyAndRename to match other oss module better.

I think that the line #undefing OSS_MIXER in kmix_platforms.cpp in the case
OSSv4 is detected should be removed for now**. The OSSv4 soundcard.h includes
the old ioctls and not compiling the other module can affect people who happen
to get binaries compiled on a system with OSSv4. 

The risk of collusion (like the case of ALSA with OSS mixer emulation) can be
removed. Since the OSSv4 (will) check version after this patch it shouldn't
collide on systems with an OSSv3 mixer. The other option is collusion on an
OSSv4 system.
If the check is sequential (i.e. always per the order in g_mixerFactories),
than there's no need to change anything since the OSSv4 check will always run
before the regular OSS's module check (This happens to match my observations,
but maybe that's only on my system?). Otherwise, we can add the version check
in reverse to the OSS mixer module.

** line removal tested on my system without issues. Not included in attached
patch.

Created attachment 26297 [details]
Attachment to improve OSSv4 support

One more thing - set masterChosen to true after setting m_recommendedMaster.
OSS4 may mark more than one device with MIXF_MAINVOL (main output, center,
left, etc.) and recommending the first is more typically correct (and neater in
the code).

I also can not launch kmix once oss 4 has been installed.  This is a pretty large issue as many users with new sound cards are having trouble using alsa, and we need a gui app other than the unusable ossxmix to change our audio.  This issue must be fixed before the oss guys can help to get oss4 working with phonon.

It seems that this bug is fixed.
I've just upgraded to kmix 2.6.1 (KDE 3.5.10) - there is no any mixer to choose, see screenshot: http://ipicture.ru/uploads/080827/876/sPyClmjnTa.png

dpkg-reconfigure linux-sound-base and activating Sound System from Kcontrol didn't helped.

Is it kubuntu-related issue or more global?

I added the patch from comment #10. The patch got a reject of hunk 3, because it stated "m_backendSysinfo.numMixers" instead of "m_backendSysinfo.nummixers", but I fixed that.

Please somebody with OSS4 checkout the KDE3.5 branch, compile, run, and report back here.

Well, since I made that patch, I can't test it objectively :-)

I do have two questions:
A) What are the chances of this making it into KDE4?
B) A problem here is that OSS4 isn't typically distributed with distros, so most won't compile kmix with support for OSS4 (they'll use the older <soundcard.h> which comes with Linux). Moreover, OSS4 typically does not replace /usr/include/sys/soundcard.h with its own soundcard (so a compile requires some manual fiddling).
I wonder if the OSSv4 <soundcard.h> can be included with kdemultimedia source provided it is under a BSD license? If so, A --enable-oss4 switch can be used to make the choice in compile-time.

*** Bug 170013 has been marked as a duplicate of this bug. ***

actually...it works now. Needs some work with the channels but front, pcm do work.

Yair,

about your questions.

A) I don't object to OSS4 support in KDE4. But your patch is not compatible with KDE4 - I can tell you that for sure without event taking a look (mixer_backend.h is different, and especially the Volume class has changed drastically). I won't convert it, but will accept patches.

B) No, it can't be included. Not for license reasons, but for technical reasons. Including a foreign library header (like <soundcard.h>) is always a very bad idea (you just need the header matching your installed library, so everybody needs different ones). But if somebody knows cmake, it should be able to write a rule to find the correct headers for "--enable-oss4", if there is some standard place for them.

Created attachment 28214 [details]
Fix bug which prevents compile

Hi,

The OSS API is an ioctl based API not a library based one, so I believe the problem of binary incompatibility doesn't apply here. GStreamer is including a copy of <soundcard.h> without any issues I'm aware of ( http://cvsweb.freedesktop.org/gstreamer/gst-plugins-bad/sys/oss4/oss4-soundcard.h?revision=1.1&view=markup ). IMHO, this is easier than messing with autoconf.

Btw, I made a rather nasty error in the last patch, which the attachment will fix. In addition, the OSS backend will not be prevented from building anymore if OSS4 is detected (it doesn't conflict with OSS4 backend for reasons I've explained previously). 

P.S. The original patch was made by "apriori" of the Yoper team, not by me.

SVN commit 893885 by esken:

Allow to include OSS(3) support, even when OSS4 has been detected.
The OSS(3) source is already "#include-d" before this patch, so it
should not do any harm.
Further rationale can be read in 
https://bugs.kde.org/show_bug.cgi?id=166591#c18
CCBUGS:166591


 M  +0 -1      kmix-platforms.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=893885

Yair,

I added your latest patch ("Fix bug which prevents compile") to the KDE3.5 branch.

I won't add the "soundcard.h", for the following reasons:

1) Detecting OSS4 even on OSS3 systems. One could write an autoconf macro to detect that, but well ... 

2) Obeying the recommendation in the header file you linked to:
  "The latest version is always installed together with OSS use of the latest version is strongly recommended."

3) Wrong values on compilation, like version number of the driver.

4) Possibly the header is to new, claiming that there are values/ioctls that actually don't exist in the installed driver.


It would be easier to include a OSS4.readme in the distribution.

Christian,

  I don't think what you describe is a problem, because:
  1) Kmix OSS4 module is using runtime detection of OSS version via OSS_GETVERSION ioctl anyway. If version is too low or the ioctl fails, then the module loading fails too and afterwards kmix will load the "regular" OSS module. So there's no case of "detecting OSS4 on OSS3 systems" unless the drivers intentionally lie (we can have a --disable/enable-oss4 switch for the paranoid).

  2) I was thinking of keeping the use of system soundcard.h in OSS3 module, and only using OSS4 soundcard.h in OSS4 module, so 3&4 objections don't apply (this is what gstreamer does). In practice, use of OSS4 soundcard.h would still work on OSS3 systems**, but having the OSS3 module always include the OSS4 soundcard.h is an unnecessary change.

  3) The OSS4 API keeps binary compatibility, so using a slightly older version of soundcard.h then the current OSS4 won't cause any trouble (I'll note that 4front contracted the Gstreamer oss4 module, so I don't think they'll object to using soundcard.h here too).

** This is because the subset ioctls/defines that Kmix uses in OSS3 module is shared by both OSS3/OSS4. Having ioctls exist in header but not in system, does not make Kmix use/rely on them so obj. "4" doesn't apply.
 Since OSS4 soundcard.h is a superset of the OSS3 soundcard.h, with some small exceptions that don't interfere with kmix (no SOUND_PCM_READ_* ioctls, slightly different SOUND_MIXER_* ioctls once you pass the first 20 ones, but kmix uses MIXER_WRITE() anyway), I don't think obj. "3" applies either (An OS could theoretically write its own soundcard.h and remove binary compatibility by defining a different representation of the ioctls, but I've never seen one which does it, as there's no reason to).

Yair,

1)+3) Yes, this could work, probably. But we are also doing compile time detection in kmix-platforms.cpp, including the version number from the header. It should probably be redesigned anyways (using something like HAVE_SOUNDCARD_H and HAVE_SYS_SOUNDCARD_H and HAVE_LIBASOUND2).

2) Ah, that is better. It will work technically.

OK, lets do some more checking:

Licensing might be an issue, because in http://cvsweb.freedesktop.org/gstreamer/gst-plugins-bad/sys/oss4/oss4-soundcard.h?revision=1.1&view=markup there is a reference to the BSD license, which might mean that we cannot use it. It is not possible if it the original BSD license is meant, because we can't mix that with GPLv2. Unfortunately. there is not a proper license header included in the oss4-soundcard.h, so we cannot know for sure. :-(
Yair, what do you think?

Using something like "export INCLUDE_PATH=/path/to/oss4/include" sounds like less hazzle (a proper cmake check would even be better).

 Christian

Any chance in getting this into KDE 4.x? I've been stuck with empty KMix window for over a year now...

BTW, there is now brand new Qt4 OSS 4.1 Mixer.

http://www.qt-apps.org/content/show.php/Osso?content=102914

Maybe this app would be useful to add support to KMix-kde4?

Lukas, for getting it into KDE4, please read comment #17. Unfortunately it looks like nobody was interested too much yet.

Created attachment 34413 [details]
Patch from Yoper ported to KDE4 version of kmix

Hi, I kinda "ported" the proposed patch, which means it does compile using kde4 svn sources.

However, I am not an OSS or KDE developer at all, which means that kmix compiles and runs with this patch, but the result is not so functional here...
You will also notice that I added a static include to the CMake file, which is bad. OSS documentation says that the right way to find the header is to source the file /etc/oss.conf which defines OSSLIBDIR, where we can get our include. The reason why I did not implement this solution is simply that I have *no* idea how to do that with CMake ;-)

Anyway, I hope my little contribution will help in some way.

Created attachment 34417 [details]
Updated version of the OSS4 patch for kmix on KDE4

I just realized that I worked on the initial patch by Yoper and did not take into account any of the subsequent modifications that were posted in this bug report. So I integrated them in this new version of the patch, which obsoletes my first posted file.

PS: sorry to followers of this bug for my multi-posting

Thanks for adapting the patch to KDE4. :-)

I integrated that into my local KMix checkout.

Target Milestone ist KDE4.4. I'll commit that to the KDE SVN after KDE4.3 is branched (I do expect this to happen in July 2009).

Some words about the patch:
a) I kept the static include dir in the CMakeList.txt, as I don't know how to do that in a proper way with CMake either.
b) I needed to guard the OSS4 usage with "#if SOUND_VERSION >= 0x040000". It basically looks now like the KDE3.5 code (see http://websvn.kde.org/branches/KDE/3.5/kdemultimedia/kmix/kmix-platforms.cpp?revision=893885&view=markup ).

Christian any chance can you attach the updated patch here or - even better - commit it? I'm happy to test it.

I have now commited the code to KDE trunk (as planned, see comment #29. The required branch was done end of june '09).

Those who compile trunk themself can test that now.
Please be aware that I needed to merge in the latest trunk changes w/o the possibility to check whether it compiles and works. Please let me know of any issues.

  Christian

Compiles & works!

Sorry Christian, I neglected replying to #22.

  OSSv4 isn't BSD/CDDL/GPLv2 licensed in the sense that "All the conditions of all the various licenses apply to all the files", but in the sense that "There are separate releases containing (almost) the same source under each of the different licenses"[1]. So there's a BSD (only) release, CDDL (only) release and a GPLv2 (only) release. You can just take the soundcard.h from a GPLv2 source release[2] (which is identical to the others), and none of the conditions of the CDDL or BSD would apply to you.

  I think including an OSSv4 soundcard.h is an easier solution since binary distros could compile OSSv4 support in without putting OSSv4 on the build machine or placing their own copy of <soundcard.h> somewhere (This would make asking distros to include the OSSv4 support much easier). It will also be easier for users since compiling will require one less step.

[1] http://developer.opensound.com/opensource_oss/licensing.html
[2] http://www.4front-tech.com/developer/sources/stable/gpl/

Created attachment 35061 [details]
Readd version check

The version check got lost in the translation to KDE4. This small patch adds it back.

SVN commit 991816 by esken:

Add version check, as reported in bug 166591.
CCBUGS: 166591


 M  +4 -0      mixer_oss4.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=991816

Yair, thanks for the patch. I submitted it right away.

About the soundcard.h request: I really wished we could discuss this form person to person. Things like theses are sooo tedious to discuss in emails or a bug system. :-¦

I am wondering, whether we would then ALWAYS detect OSSv4, even with OSSv3. I am aware that we discussed this already. I just wonder whether it is solved with the version check just commited?!? Comments appreciated.

In any case, I would like a comment from:
- 4Front, whether this is a good idea
- kde-licensing (I don't expect issues there)
- kde-core-devel (might argue, e.g. that every MM app must then include the soundcard.h)

  Christian

Created attachment 35074 [details]
Fix capture volume setting

Christian,

The attachment is another patch:
A. Changing volume of capture devices was broken (readVolumeFromHW/writeVolumeToHW just assumed md->playbackVolume was used and didn't check for md->CaptureVolume).
B. Don't throw useless error message if system's OSS doesn't support OSS_GETVERSION (Old versions of FreeBSD didn't have this).
C. Don't ignore mute switches anymore (no reason to).

Christian,

"I really wished we could discuss this form
person to person."

Well, there's the #oss Freenode IRC channel.

"I am wondering, whether we would then ALWAYS detect OSSv4, even with OSSv3. I
am aware that we discussed this already. I just wonder whether it is solved
with the version check just commited?!?"

Well, I don't think testing for OSS_GETVERSION at runtime is any worse than testing for SOUND_VERSION at compile time...

"In any case, I would like a comment from:
- 4Front, whether this is a good idea"

OK, I'll bug them on their mailing list[1], and get back here.

"- kde-licensing (I don't expect issues there)
- kde-core-devel (might argue, e.g. that every MM app must then include the
soundcard.h)"

The latter kde-core-devel idea is excessive. Most apps use only OSSv3 API (directly or via phonon), so no need for another soundcard.h (OSSv4 tries to be compatible with OSSv3 API). Kmix is exceptional, since a backend there must rely on an exclusive OSSv4 API. I can't think of another case that would fit this criteria, except maybe kmid - if the OSSv4 devs ever actually implement their MIDI API, which doesn't seem to be the case in the near future.

[1] http://mailman.opensound.com/pipermail/oss-devel/

Hi all.
I was the original author of the patched and didn't have time to further improve it. However, I had enough time to fix some bugs of the kde4 port version of this patch.
-enums should be working again and are again represented with menus
-MIXT_STEREOSLIDER16 controls should at least partially work. The volume scaling is still wrong (will contact the oss devs about that)
-merged in last changes of Yair K.
-search for tokens "vmix", "mute", "pcm", "in" instead of substrings preventing matches like code1.jack.int-speak1 for "in", which is not a capture control

I also noticed a bug in kmix4 which is more bound to its underlying API:
If you move to another slider control while moving a slider the results are pretty much undefined. In my case I ended up writing random values to random controls. Kmix should properly handly such cases in which a user refocuses another control while holding the mouse button down. Of course it's possible that I didn't notice a bug in the OSS4 backend.

@Yair K.: As for mute controls I'd rather map them and register them at their respective parent controls.

About the general process: I'm honestly not too happy with the slightly limited kmix API. Especially the reworked API part "addCapture/PlaybackVolume" was confusing, but I assumed you plan to allow connections of several controls.
Kmix is simply not intended for hierachical mixers like OSS exports them. 
Whereas an attempt to fix this would result in a complete rewrite of kmix, I'd just one extra functionality (and will soon patch it in): The possibility to deactivate controls, because the OSS mixer API allows controls to be temporarly disabled (e.g. due to mixer layout changes).

Best regards and keep up the good work Christian

Armin Kazmi

Created attachment 35220 [details]
-match tokens instead of substrings, fix enums broken by kde4 port

Created attachment 35264 [details]
kmix is unmutable 

The mute box for vmix unticked.

The latest patch seems to properly expose the OSS mixer elements. However, right now I can not untick the 'Virtual Mixer0 Enable' Mute box. And this may be the reason that I still got no sound with the OSSv4 + kmix combination at all.

I have to sure kmix is not running end my KDE session. Log back in, start ossxmix and change the mixer settings with ossxmix.

Mixer, does actually work. Just that kmix currently does not seem to know what the default master channel is. Once that was manually selected it worked liked a charme.

The mute tickbox ( https://bugs.kde.org/attachment.cgi?id=35264 ) is still locked though.

Created attachment 35280 [details]
a new patch, to be applied with patch -p1

-reverted back to substring matching (tokens approach was not too successful with e.g. hdaudio cards)
-implemented master volume search heuristic (defaults to first vmix outvol slider if no control exports MIXF_MAINVOL)
-some tiny more detailed errormessages
-added more classifiers
-fixed logical error in handling of MIXT_ONOFF controls
-new base value "minvalue" for MIXT_ONOFF/MIXT_MUTE controls instead of "maxvalue" (some drivers export a bogus value of 2 for maxvalue)
-MIXT_MUTE controls will still be skipped (hdaudio got > 10 mute controls, which would flood the layout)

Created attachment 35281 [details]
prior patched contained a mistake

-fix: vmix.*enable controls were accidentally skipped, too

Your latest version of the patch does fix the untickable mute tickbox.

However your previous version of the patch enabled the application independent volume control in kmix ( see here : http://bugsfiles.kde.org/attachment.cgi?id=35264 ) . The new version has lost this support.

@Tobias:

Actually this was done on purpose and was a bug in the kde4 port of the patch. In OSS4 you can choose the amount of available vmix engines, which defaults to 4 (if I'm correct). Modifications of this value can result in more sliders flooding the layout. Besides, all old legacy OSS applications don't behave too well with modified vmix engine volume levels. This was the case with OSS 4.1 prior 1052b, I'm not too sure about the current state of this issue, though.
For now I recommend that you test this specific issue again. E.g. try to use an oss app without with only old legacy oss support, lower the volume of the vmix engine, close the app and open another oss app. If the volume remains at zero, the bug (well, that behaviour may even be expected by the devs, but its not by the users) is still valid. The point is, an old oss app must not modify the volume for applications which use the same engine slot after them, so shouldn't the user. But with the mentioned bug the user expects to control the applications volume (which is even true) but he also permanently modifies the volume for applications later using the same slot.

However, if you really want the vmix engine sliders back, simply comment out line 137 in the patch, or line 308 in the resulting mixer_oss4.cpp.
Note that neither I think this approach is optimal. I'd really prefer to simply include all possible controls and read the controls description text (which contains the name of the current app using the respective vmix engine).

If you find out that the bug is no longer valid, please report back and I'll revert the change.

Regards

Armin

@Armin:

Since OSSv4.0 build 1016, setting the initial number of vmix engines (default: 4) can be done only at compile time. OSS from that version on will automatically create more engines if more than 4 programs are using vmix, but kmix won't pick that up - it only probes for mixer controls during open, so it won't pick up the new engine at all... (ossxmix can pick them up, because it polls the device for total number of controls and refreshes if it changed).

As for the bug, old OSS programs are not aware of the new API, so I don't think they should be able to change the engine volume at all... Can you name a program which provokes this bug?

@Yair K. 

I'd recommend discussing this is issue in the Open Sound Forums, since its out of the scope of kmix. Looks like I didn't recall this issue properly.

http://4front-tech.com/forum/viewtopic.php?p=12869#12869

Yair & Armin,

I really got a bit confused about the discussion, and whether that influenced which of the patches should be applied (if any). Looks like there is not a real consensus yet?!? Some clarification would be nice. I'll wait with applying anything until that.

 Greets,
     Christian

While I was trying to look into some other issues I noticed that kmix is constantly using about 4-5% of CPU resources ( in top ). I recall a similar thing with ossxmix due to device polling or similar.

I am using the latest OSS v4 patch right now. I do not have an alsa system as reference around for the next days.

Chris, Tobias,

Armin's latest attachment is good. We were just discussing about how to improve it further, but I have no objections to his patch. Tobias raised a very interesting question about kmix CPU use, and from my investigation improvements can be made that affect the other polling-based backends as well:
  A. kmix keeps polling even while it's in the background (minimized to tray or iconified). Is there a use case for that? It should be possible to have kmix poll the device only while in foreground or invoked (via multimedia key), but perhaps I'm missing something?.

  B. kmix polls the device every 50ms. This seems excessive, and (IMHO) can be doubled (or more) safely. I pulled the source for other mixer program available in Debian (some quite old), and in the comparison kmix is definitely at the low end. Out of 14 programs checked, all except 2 had at least 100ms timeouts.

  C. The OSSv4 backend needs to check for modify_counter (from SOUND_MIXERINFO IIRC?) every poll. If it's unchanged, than the mixer hasn't changed and it can stop the current round of readVolumeFromHW polling.

I suspect the above will reduce CPU use significantly. I'll do C) sometime soon.

[1]
 ossxmix: 100ms for main polling loop.
 gstreamer: This depends on the driver, and I didn't check most, but oss4 plugin uses 500ms "mixer watch interval".
 wmmixer: 100ms sleep in the main loop.
 aumix: 1000ms "refresh timer".
 mixer.app: 50ms sleep.
 asmixer: 250ms sleep.
 tkmixer: 200ms ("after 200").
 xmix: no polling.
 volumecontrol.app: 500ms timer.
 wmix: 100ms sleep.
 rexima: no polling - every keypress makes a refresh.
 wmrack: 50ms sleep.
 gom: 5000ms sleep?
 gpe-mixer: 500ms timeout.

Created attachment 35450 [details]
Armin's patch + check for modify_counter

Attached is the latest patch from Armin with a check for modify_counter in a new prepareUpdateFromHW() function added. Tobias, does this help?

I have tried the changes from Yair . These reduce the CPU load to about 50-60 of the previous version. It is still one of the most CPU hogging applications in my system but it does that at significantly less expense than before.

Since there was a confusion , of who is using what patches I just supply what I've used.

Created attachment 35583 [details]
backport of ossv4 support to 4.3 branch

cummulative patch including all previous patches cleanly diffed against trunk / 4.3 branch

Created attachment 35584 [details]
Yairs modification that reduce CPU consumption of kmix by ~ 50 %

Comments to Yair's comment 52:

--- First some calculations -----
Yes, 4-5% is excessive. So lets check: Using KMix with ALSA for one hour:

chris@firefly:~ # ps --cumulative -p 5506 -o pid,cmd,pcpu
  PID CMD                         %CPU
 5506 kdeinit4: kmix [kdeinit] -s  0.0
chris@firefly:~ # cat /proc/5506/stat | cut -d" " -f14-17
66 12 0 0

The "stat" output shows, tha KMix took 78 jiffies (and I am running it for 1 hour). 78 Jiffies as shown in /proc/pid/stat should be 780ms. And 780ms/3600000ms = 0.0000216, so approximately 0,002% CPU.

So is the CPU usage probably exclusive to the OSS4 backend? I haven't seen such a high usage in OSS3 either.
-----------------------------------------------------------------


About A. kmix keeps polling even while it's in the background (minimized to tray or iconified). Is there a use case for that? 

Answer: Yes, for the tray control - it shows the volume level (muted, or low, medium, loud volume).

B. The change to 100ms be done. In a "live display" the delay is noticable, but we shouldn't care. Anyhow, why does it show up on the OSS4 backend - doesn't it use a ::poll() like call?

SVN commit 1005823 by esken:

Chnages to OSS4 backend, as submitted in BUG 166591 Comment #53

-reverted back to substring matching (tokens approach was not too
successful
with e.g. hdaudio cards)
-implemented master volume search heuristic (defaults to first vmix outvol slider if no control exports MIXF_MAINVOL)
-some tiny more detailed errormessages
-added more classifiers
-fixed logical error in handling of MIXT_ONOFF controls
-new base value "minvalue" for MIXT_ONOFF/MIXT_MUTE controls instead of "maxvalue" (some drivers export a bogus value of 2 for maxvalue)
-MIXT_MUTE controls will still be skipped (hdaudio got > 10 mute controls, which would flood the layout)
-fix: vmix.*enable controls were accidentally skipped, too

-reduce CPU consumption by ~ 50 % (for OSS4 backend)

CCBUGS: 166591


 M  +232 -73   mixer_oss4.cpp  
 M  +4 -1      mixer_oss4.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1005823

Chris,

  ALSA's mixer API can use select() call, but OSS4 (and all other non-ALSA kmix backends, per grepping the kmix source for "prepareUpdateFromHW" function) use a polling based API. Due to the API, the polling based backends are doomed to have some level of CPU use, since the only way to find out when they are updated is to wake them up and poll them (select() is probably implementable for OSS4 mixer API, I guess?).

  Now, OSS4 exposes way more controls in the mixer than most other drivers (OSS3 in particular), especially so for the oss_hdaudio driver which Tobias is using (you can see this in the screenshot he attached earlier). This means there is more polling done in the loop, and thus Tobias saw a much higher CPU use since all of these controls were polled every 50ms.

  Fortunately, the OSS4 API allows a program to poll whether the mixer has changed at all, so the cost for the typical case (where mixer is unchanged) can be reduced to one ioctl call (mixer changes are still expensive, but they are much rarer). After the change committed, CPU use is very slightly lower in OSS4 backend than the OSS3 one on my system**.

** Both tests done using OSS4 driver (OSS4 drivers for some cards support the OSS3 mixer API too). I tried also testing the OSS3 backend using the ALSA drivers for my card loaded, but for some reason kmix didn't work at all***. The ALSA backend CPU use is almost nonexistent.

*** I commented out both the ALSA and OSS4 backend, and tried running kmix. I got this error:
<unknown program name>(7314)/: Communication problem with  "kmix" , it probably crashed.
Error message was:  "org.freedesktop.DBus.Error.NoReply" : " "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken." "

Interestingly, the program still appears in top output, so it doesn't really crash. Just no window is displayed..

Sorry, for bad error report above. I forgot to load the OSS mixer emulation module...

OSS3 mixer backend CPU use: average 2.0% per "top" using both OSS4 or ALSA drivers. 
OSS4 mixer backend CPU use: average 2.0%. Probably no real statistical difference with OSS3 backend.

Here the stats from my system.

tobias@Yoper ~ $ ps axu |grep kmix
tobias    4291  1.8  0.8  62820 18080 ?        S    09:11   2:45 kmix -session 10cb6f7065000124918525000000045230008_1249244197_255156
tobias    5200  0.0  0.0   4096   816 pts/2    R+   11:44   0:00 grep kmix
tobias@Yoper ~ $ ps --cumulative -p 4291
  PID TTY          TIME CMD
 4291 ?        00:02:46 kmix
tobias@Yoper ~ $ cat /proc/4291/stat | cut -d" " -f14-17
6365 10347 0 0
tobias@Yoper ~ $ uptime
 11:45am  up   2:37,  1 user,  load average: 0.21, 0.12, 0.10
tobias@Yoper ~ $ echo $[6365+10437]
16802 

Not sure I repeated your maths correctly, but that's what I get :

16802 / (157 minutes uptime * 60000 ms)
0.00178365180467

Compiled on x86_64, and works good.  OSS support appears to break multimedia volume keys though.  OSD shows up but at 0% and if I push it enough times, kmix goes boom.  Want me to file a separate bug for this?

(In reply to comment #63)
> Compiled on x86_64, and works good.  OSS support appears to break multimedia
> volume keys though.  OSD shows up but at 0% and if I push it enough times, kmix
> goes boom.  Want me to file a separate bug for this?

IIRC this is an issue of the support patch and not a separate issue. It's a known deficiency of the current patch. Armin has stated this and mentioned he'll look at this after summer, when he got time again.

Bug 212944 is about the last described issue (volume shortcuts). There is a patch which works, but is fixing it at the wrong place. Correct would be to implement Mixer_OSS4::id2num().

I'll close this bug report. People encountering the shortcut problem should follow Bug 212944.