From alsa-devel-owner@alsa.jcu.cz  Thu Feb  4 09:34:26 1999
Received: from entry.jcu.cz (IDENT:perex@entry.jcu.cz [160.217.1.111])
	by marvin.jcu.cz (8.9.1a/8.9.1) with SMTP id JAA30480;
	Thu, 4 Feb 1999 09:31:06 +0100
Date: Thu, 4 Feb 1999 09:31:06 +0100 (CET)
From: Jaroslav Kysela <perex@jcu.cz>
To: Martin Pahl <pahl@tnt.uni-hannover.de>
cc: alsa-devel@alsa.jcu.cz
Subject: Re: Questrion to kernel-code 
In-Reply-To: <199902040811.JAA28710@sokrates.tnt.uni-hannover.de>
Message-ID: <Pine.LNX.3.96.990204091829.8764D-100000@entry.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

On Thu, 4 Feb 1999, Martin Pahl wrote:

> I hope not to bother you to much, but I really want to get my driver
> for ZA2 going. Recently I found this line in
> pcm1_native.c:snd_pcm1_user_to_buffer:
> 
>                 pchn->hw.dma(pcm1,
>                              pchn->buffer,
>                              (pchn->head * pchn->block_size) + pchn->frag_size,
>                              (char *) buf, tmp);
> 
> This line calls the driver specific routine for placing the data into
> dma-buffer (I just use the default snd_pcm1_playback_dma_ulaw). Ok, my
> question is: What is the meaning of pchn->frag_size? I set the minimal
> fragment to 6 in my snd_stru_pcm1_hardware as I thougt it is the
> minimal fragment to transfer to card. But as I saw the mentioned line, 
> I'm really not sure about the meaning of the fragment size. Is there
> any connection between the minimal fragment size in
> snd_stru_pcm1_hardware and pchn->frag_size?

The fragment size (from application view) is stored in variable block_size
and variable frag_size means size of partly filled fragment (this
variable doesn't have any connection with the lowlevel driver).

Using of snd_pcm1_playback_dma_ulaw function isn't 100% correct for 8-bit
samples (mu-Law routines in ALSA uses 8-bit unsigned format) in your case.
For the correct function you should create own DMA transfer routines
which will convert 8-bit samples to 16-bit. You can find code in
alsa-driver/lowlevel/sb/sb16.c source (8to16 and 16to8 functions). But I
still don't understand why 16-bit streams aren't working.

Maybe you can try printk some values from DMA buffer in trigger() function
and compare them with input. Only for sure if ALSA midlevel code works as
you expect. It isn't also bad printk snd_dma_residue() result in interrupt
(only for sure if DMA is working properly)..

							Jaroslav

-----
Jaroslav Kysela <perex@jcu.cz>
Academic Computer Centre, University of South Bohemia
Branisovska 31, C. Budejovice, CZ-370 05 Czech Republic


