Re: SB and 2.1.126 [NOT THE COMPILE PROBLEM]

Jamie Lokier (lkd@tantalophile.demon.co.uk)
Thu, 29 Oct 1998 14:43:12 +0000


On Thu, Oct 29, 1998 at 11:32:05AM +0100, Thomas Sailer wrote:
> Jamie Lokier wrote:
> > I'm not sure which way round an internet telephone program would prefer
> > -- 16 bit recording might produce a clearer encoding to send, but 16 bit
> > playback permits better filtering on the reconstructed signal at the
> > receiver.
>
> Why? You can always internally use a higher resolution to do the filtering.
Agreed, at voice rates anyway.

> Also, you could use software AGC techniques to fully use the available
> 8bits on playback.
Not agreed. I don't think you can synchronise the volume changes with
the output sample accurately enough to avoid glitches.

> You usually cannot do this on recording (other
> than writing on the screen "please come nearer/go farther away from the
> microphone :-))
:-)

> > A game with atmospheric sound effects and also a chat capability between
> > players would surely prefer 16 bit playback, so that the subtle effects
> > produced by the sound generator can be heard.
>
> The program can open the sound device with O_WRONLY to make it
> possible for the driver to use 16 bits for output.

Not with the chat capability at the same time. Recording is needed to
relay the local player's voice. Note, I neglect to mention the
complexities of echo cancellation of the sound effects etc. :-)

Or... can the program open the device O_WRONLY and again O_RDONLY, so
it can control the playback and recording channels separately? That
would do nicely.

> Otherwise, it might be more easy to buy a soundcard with decent PCM
> section 8-)

Maybe :-)

I mention this because as an ex-game-programmer, I would want to be
able to be able to set playback to have 16 bit priority.

Perhaps the ideal solution would be:

If /dev/dsp is opened O_RDWR, whatever policy you prefer. Sounds like
16 bit record/8 bit playback is the way to go (SB16 only, I know).

If /dev/dsp is opened O_WRONLY (or O_RDONLY), it may then also be opened
O_RDONLY (or O_WRONLY) giving independent file descriptors for each
direction. In this case, if one descriptor is set to 16 bit mode, that
mode is made unavailable for the other channel (SB16 only). Or perhaps
it is still available (with automatic conversion to 8 bit in the
driver), but not advertised.

This allows the application to choose the mode it prefers from those
that are properly supported. (Do any applications do this? Yes they
do, I've written one).

> Remember: THe problem case is only programs that open the sound
> device with O_RDWR and only on SB16. No other card I know of
> has this silly limitation.

Quite. But they are quite common.

-- Jamie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/