Hi Hannu, yes, all your comments about 1) are already implemented. However, apparently I found a bug in the hd audio driver, because I monitored the value of code1.jack.int-speaker1 (ossmix -D) while adjusting the slider in ossxmix. There is no way to get beyond a value of 299 for me, whereas 399 is expected. You also don't notice the sound to become louder above the 75% position in ossxmix. Scaling as mentioned in 2) is already implemented (well, actually its bypassed/not needed, because kmix does allow arbitrary values for min and max). I just thought becauseo the error I noticed the implementation is wrong, but it isn't. The one thing why we notice the problem in kmix and don't notice it in ossxmix is, that kmix immediately rereads the written value for verification purposes and readjusts the slider to the actual reported position. Therefore you simply can't lift the slider above 75% with this error.
The codec I got from dmesg is (ALC883): oss_hdaudio: Unknown HDA codec 0x10573055 oss_hdaudio: Unknown HDA codec 0x10573055 There were still some problems trying to figure out the main volume control, though. The current approach assigns the first vmix outvol control slider as master volume control, if no other slider control has flag MIXF_MAINVOL set. Regards apriori > apri...@dkc-clan.de wrote: > > Hi ossdevs, > > > > the kmix patch progressed further in my absense. However, there are still > > plently of bugs with the implementation that need to be fixed. Those bugs > > are actually only a consequence of my lack of knowledge about the OSSv4 > > mixer API. So I've got the following questions (for now): > > > > 1) How do I find the proper maxium value of a control? > > The docs mention that it's possible that actually only a discrete range > > of values between ext.minvalue and ext.minvalue are supported by the > > underlying device (with automatic rounding etc.). Now I've got an HD > > audio (ALC883) here with the control "code1.jack.int-speaker1" of type > > MIXT_STEREOSLIDER [ + MIXF_CENITBEL ], with minvalue 0 and maxvalue 399. > > However, the maximum value (set with ossxmix before) reported when > > reading from the mixer is 299, which is about 75% of maximum. I've > > browsed the source of ossxmix, but I don't really understand how it does > > detect the actually supported maximum. Currently the maxvalue-minvalue > > range is used by kmix and applied to the respective slider. So with this > > approach 100% volume in ossxmix for this control matches 75% in kmix, > > which is obviously wrong. I wonder whether a better a approach for > > sliders would be to allow 0-100 only (or 0-1000 for finer granularity) > > and write [ ext.minvalue + (sliderValue/100) * (ext.maxvalue - > > ext.minvalue) ] to the mixer. > > The actual value that the control can have (in ioctl calls) is between 0 > and maxvalue for continuous controls like MIXT_STEREOSLIDER. For > MIXT_ENUM maxvalue is the number of choices. > > The minvalue field as well as flags like MIXF_CENTIBEL are used only > when the value is displayed on screen. For example if the value is 100 > then the application can print "10.0 dB" instead of just "100". However > this is completely optional. > > > 2) How do I need to handle MIXT_HEXVALUE and MIXT_VALUE? > > These types are currently only used in read-only controls that show the > current sampling rate or some other values. The difference is that > MIXT_VALUE is shown in decimal and MIXT_HEXVALUE in hexadecimal. > > http://manuals.opensound.com/developer/SNDCTL_MIX_EXTINFO.html gives > some info about the control types. Scaling of the values is explained in > http://manuals.opensound.com/developer/mixer_value_scaling.html . > > Best regards, > > Hannu > _______________________________________________ > 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
