Source-Changes archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/sys/dev/ic



On Sun, Sep 28, 2003 at 10:24:09PM +0000, Quentin Garnier wrote:
> 
> Module Name:  src
> Committed By: cube
> Date:         Sun Sep 28 22:24:09 UTC 2003
> 
> Modified Files:
>       src/sys/dev/ic: ac97.c
> 
> Log Message:
> Change the way of setting a port value so that a change too small to
> fit in the number of bits used for the port still does something.
> 
> This fixes PR pkg/18741 for ac97-based hardware. Other audio drivers
> might need a similar fix.

Quentin,

Sorry I did not respond to your previous e-mail on this topic. I had
misgivings when I read what you wanted to do, but I did not have the
time to write back.

I do not think that the kernel should second-guess the application this
way. I think that most apps are (or will be) written with the expectation
that the mixer settings are stateless. I.e., if I write volume=1 when
the volume=0, then it should produce the same volume as when volume=1
and I write volume=1, namely volume=1.

It will complicate more apps than it simplifies if the assumption of
statelessness does not hold.  Just for example, suppose I have written an
application that "pans" the audio from the left to right channel. My app
produces volume numbers l and r between 0 and 1 for each channel. To set
the volume in each channel, the app calls the appropriate mixer ioctl
with (int)(l*255). If I am using an ac97 with 5-bit volume registers,
then the volume is going to snap prematurely to the next higher level
when (int)(l*255) changes from 0 to 1. I will have to complicate my
hypothetical program to avoid the snapping. Just off the top of my head,
I would write volume settings to the kernel, and then read them back
again to find out which ones "took." That way I can find out where the
snaps will occur so I can avoid those values. Ugh, complicated.

I think that to fix pkg/18741, mp3blaster should be changed so that
it uses mixer ioctls to find out the width of the volume registers,
and adjusts the granularity of its audio adjustments to suit. So that
mp3blaster does not have to make a bunch of assumptions about the volume
register, maybe there should be a mixer ioctl that tells its numeric
range and/or least significant adjustment?

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933



Home | Main Index | Thread Index | Old Index