OSS4 support for kmix-3.5.9 [NEW:In kmix, testing requested]

[apriori]

[edit by cesium: The patch has been integrated into kmix:
https://bugs.kde.org/show_bug.cgi?id=166591#5 and https://bugs.kde.org/show_bug.cgi?id=166591#13. The commiter would like to have this tested more. For that, you'll have to fetch kdemultimedia from the SVN branch for KDE 3.5, replace /usr/include/sys/soundcard.h with the file /usr/lib/oss/include/sys/soundcard.h, and (try to) use kmix from the complied kdemultimedia.]

Hi all,

I've reworked my kmix patch a bit, removed most of the dirty hacks I discussed about with the devs on the mailing list - and now here it is. Simply apply to a clean kdemultimedia-3.5.9 tarball via patch -p1.

http://development.yoper.com/build/yoper-3.1-apriori/patches/kmix/3.5.9

Limitations etc. are mentioned in the README file at the given location. You need to know though, that this patch deactives the old OSS mixer support in kmix.

When OSS4 properly marks common controls with the MIXF_MAINVOL etc. flags, I'll rewrite the patch to reflect that.

Best regards

[cesium]

I like this. Thanks!
Note that compilation requires putting OSS4's soundcard.h in /usr/include/sys/soundcard.h .

Some prelimenry thoughts:
1. Modifying igain doesn't work. (It's stuck on zero, and any modification simply sets igain to zero. It also has an inoperative red button).
2. Some controls which are in "output" tab should be in "input" tab instead (line, mic, cd, video, phone, aux1).

[edit: The next two suggestions are probably currently unworkable because KMix has a "flat" view of the mixers]
3. I think you could limit the check for "vol", "pcm", etc. names to the group which has MIXF_LEGACY set.
4. Since you're checking for specific names anyway while searching for legacy mixers, perhaps you might as well assume that ".rec" buttons are their recording source selection, and use it for the red buttons.

[cesium]

1. Everything at "input" tab (not just "igain") fails. replacing all LEFTREC/RIGHTREC with LEFT/RIGHT seems to fix this but I'm not sure whether it's the right solution.

2. I'd suggest moving the "isCapture" check to immidiately after "classifyAndRename" is run. Than by checking cType, it will be possible to move devices to input tab without checking the name again.

Like this:

Code: Select all

MixDevice::ChannelType cType = classifyAndRename(name, ext.flags);

if ( ext.flags & MIXF_RECVOL || name.find(".in") > -1 || cType == MixDevice::EXTERNAL || cType == MixDevice::CD || cType == MixDevice::RECMONITOR || cType == MixDevice::MICROPHONE)
   {
      isCapture = true;
   }


"classifyAndRename" will need to set "RECMONITOR", etc. but that is trivial:

Code: Select all

if ( *it == "igain" )
   {
      *it = "IGain";
      cType = MixDevice::RECMONITOR;
   } else
...
if( *it == "cd" )
   {
      *it = (*it).upper();
      cType = MixDevice::CD;
   } else


etc.

[apriori]

@cesium:

Thanks for the feedback, first.

About 1: Already fixed in that way.
About 2: I've merged the isCapture check with classifyAndRename.
Added the later one, too.
About 3: No, because this function main purpose is to likely show the proper icons (if possible) and clean up the names a bit.

Currently I'm getting stuck a bit while trying to add old recsrc support and using the mute mixtexts to mute volume controls instead of lowering the volume to minval. I guess I'll need a few more hours on this.

Best regards

[cesium]

Currently I'm getting stuck a bit while trying to add old recsrc support and using the mute mixtexts to mute volume controls instead of lowering the volume to minval. I guess I'll need a few more hours on this.

Per http://manuals.opensound.com/developer/mixer_value_scaling.html:

By convention larger mixer control value means louder voice. Usually value of 0 means the minimum volume. Sometimes 0 means that the signal is completely muted while sometimes it means that the volume level is almost unaudible (in such cases there is usually a separate "mute" control for the signal). Volume level of maxvalue means loudest possible signal (unity gain or slight amplification).

So:
A. See if a MIXT_MUTE controls exists in the same group. (OSSv4.1) (Always fails on current OSSv4.0 versions - check for "mute" name instead?).
A1. If yes, turn it on. Fin.
A2. If no, turn volume down to zero. Fin.

The problem is the "same group" issue. ossxmix can afford to ignore this (because it leaves all logic to backend driver). I'm not sure how kmix can handle this...

[apriori]

@cesium:
Searching for a mute mixext or rec mixext is exactly the approach I wanted to take. Unfortunately there is pretty much I have to work around then. This will easily double the amount of code. I guess I will need a bit more time for it.

Best regards

[Temüjin]

This patch has been proposed to the Kubuntu/KDE developers: https://bugs.launchpad.net/ubuntu/+sour ... bug/123957

[NoOneImportant]

in that case, I hope it reaches the developers of kdemultimedia so that oss4 can be supported in future versions of kde4

[SeaJey]

Some good news from KDE-devs:

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?

I'm not in friendly relations with patches and other stuff, could somebody test it, please?