From alsa-devel-owner@alsa.jcu.cz  Thu Aug 20 23:11:43 1998
Received: from kawoserv.kawo2.rwth-aachen.de (root@kawoserv.kawo2.RWTH-Aachen.DE [137.226.146.2])
	by marvin.jcu.cz (8.8.8/8.8.8) with ESMTP id XAA26285
	for <alsa-devel@alsa.jcu.cz>; Thu, 20 Aug 1998 23:11:36 +0200
Received: from phoenix.kawo2.rwth-aachen.de (root@phoenix.kawo2.rwth-aachen.de [137.226.251.161]) by kawoserv.kawo2.rwth-aachen.de (8.8.0/8.6.9) with ESMTP id XAA08830 for <alsa-devel@alsa.jcu.cz>; Thu, 20 Aug 1998 23:11:26 +0200
Received: from localhost by kawo2.rwth-aachen.de
	via sendmail with smtp
	id <m0z9bzv-0006QeC@phoenix.kawo2.rwth-aachen.de> (Debian Smail3.2.0.101)
	for <alsa-devel@alsa.jcu.cz>; Thu, 20 Aug 1998 23:11:55 +0200 (CEST) 
Date: Thu, 20 Aug 1998 23:11:50 +0200 (CEST)
From: Maximilian Bisani <bisani@kawo2.rwth-aachen.de>
To: alsa-devel@alsa.jcu.cz
Subject: Re: Detecting ADC Overload
In-Reply-To: <Pine.LNX.3.96.980820213624.3156C-100000@entry.jcu.cz>
Message-ID: <Pine.LNX.3.96.980820223615.231B-100000@phoenix.kawo2.rwth-aachen.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list


On Thu, 20 Aug 1998, Jaroslav Kysela wrote:

> On Thu, 20 Aug 1998, Maximilian Bisani wrote:
>
> > My problem: How do I detect overloading?  From my experiments I found that
> > peaks get truncated to a certain maximum value.  When I record with
> > SND_PCM_SFMT_S16_LE and SND_PCM_OPEN_RECORD a signal too high gives +32767
> > (0x7fff) and a signal too low signal gives -32768 (0x8000), which I had
> > expected.  When I switch to SND_PCM_OPEN_DUPLEX (for "after tape
> > monitoring") however, the values range from -32640 to +32640 only. 
> 
> Your problems with different peak values is in your broken hardware. SB16
> (+ compatibles) have one channel 8-bit and second 16-bit. Unfortunately
> 8-bit channels can transfer only 8-bit samples and 16-bit only 16-bit
> samples. This means that driver must do conversion from 16-bit -> 8-bit or
> 8-bit -> 16-bit samples if necessary.

Thanks for your quick response.  I realy should have thought about that
myself...


> With ALSA API you can detect if driver does conversion of samples.
> Variable snd_pcm_record_info_t -> flags have flags SND_PCM_RINFO_8BITONLY
> and SND_PCM_RINFO_16BITONLY. This flags shows to application driver state.

I dont know if this is welcome, but I would like to make a suggestion:

Currently the "formats" field of "struct snd_pcm_record_info"  provides
the set of supported audio data formats and the SND_PCM_RINFO_XXBITONLY
flags tell you that some of them are supported by software emulation only.
My suggestion would be to remove SND_PCM_RINFO_XXBITONLY and introduce a
new field -- say "hdw_formats" -- into "struct snd_pcm_record_info" which
is the set of all formats which are supported by hardware without
emulation.  So for SB16 (with 8 bit DMA assigned to the record direction) 
this would be: 

    formats == SND_PCM_SFMT_U8 | SND_PCM_SFMT_S16_LE | 
               SND_PCM_SFMT_S8 | SND_PCM_SFMT_U16_LE 
    hdw_formats == SND_PCM_SFMT_U8 | SND_PCM_SFMT_S8

(Or should it be hdw_formats == SND_PCM_SFMT_S8 ???)

I believe this is more consistent and flexible as you wouldnt have to
introduce more flags if you provide more software conversion options.


> >P.S. Are you still in need of someone to improve the API documentation?
> 
> There is two documentations. One for kernel side of ALSA driver and second
> for ALSA C library + ALSA API (aka /usr/include/linux/sound.h). If you
> want extend second (from ALSA library package) - none is working on it at
> this time.

OK, I will send you my corrections/extensions to the library API docs.
Please have patience for a week or two.

Bye,
   Max



