PCM Rate Plugin

PCM Rate Plugin

[Kasparek Tomas]

Hi all,

do you know about some example for $SUBJ. I need to be able to work with
all sampling rates in UDA1341 driver for iPAQ. When I use "rec & play"
from OSS with OSS emulation, it looks, there is some resampling in
oss-emulation part of ASLA kernel code.

But for native ALSA recoding on frequency other that defined in card ends
with "arecord" saying everything is fine, but created file contains just
header. My driver is requested to capture on some near rate in this case.

Resampling on user-level is enough for me, so if ALSA has some usable
support it will be fine, but I'm not able to find it and get it running.

Thanks for your help.

--

	Tomas Kasparek (sioux, xkaspa06)
 	 tomas.kasparek@[seznam.cz,volny.cz]
	 linux@fit.vutbr.cz
	student FIT VUT Brno

Re: PCM Rate Plugin

[Takashi Iwai]

Hi Kasparek,

At Mon, 8 Apr 2002 19:24:05 +0200 (CEST),
Kasparek Tomas wrote:
> 
> Hi all,
> 
> do you know about some example for $SUBJ. I need to be able to work with
> all sampling rates in UDA1341 driver for iPAQ. When I use "rec & play"
> from OSS with OSS emulation, it looks, there is some resampling in
> oss-emulation part of ASLA kernel code.
 
yes.  snd-pcm-oss module does it.

> But for native ALSA recoding on frequency other that defined in card ends
> with "arecord" saying everything is fine, but created file contains just
> header. My driver is requested to capture on some near rate in this case.
 
well, then it's a bug of alsa-lib.
could you explain the symptom more precisely? 


Takashi

Re: PCM Rate Plugin

[Kasparek Tomas]

On Thu, 11 Apr 2002, Takashi Iwai wrote:

> Hi Kasparek,
>
> > But for native ALSA recoding on frequency other that defined in card ends
> > with "arecord" saying everything is fine, but created file contains just
> > header. My driver is requested to capture on some near rate in this case.
>
> well, then it's a bug of alsa-lib.
> could you explain the symptom more precisely?

I have solved this yet. Original behavior (using "pcm.default") was:

- using rate supported by card -> mono and stereo capture works

- using non-standard rate -> just stereo works (that is native for the UDA
  chip), for Mono "arecod" produces just 44bytes of header.

I solved this using own configuration:

pcm.h3600 {
type plug
slave  {
pcm {
    type hw
    card 0
    }
#format "S16_LE"
#channels 2
rate "unchanged"
}
}

I need to specify the "rate" line. Then resampling and mono <-> stereo
transformation works fine. I tried sample format conversion, but it does
work well just with my configuration too. (I tried S|U 16 LE|BE, MU_LAW)

The card is UDA1341TS on H3600 (iPAQ) - native support just for U16_LE,
stereo.

Weel, I would like to ask one more question: The chip sipport not only
16bit(LE) samples but 18 and 20 bits LE samples too. Would it be hard to
update ALSA to support these sample sizes? Where should I look for
informations when trying to get this running?

Bye

--

	Tomas Kasparek (sioux, xkaspa06)
 	 tomas.kasparek@[seznam.cz,volny.cz]
	 linux@fit.vutbr.cz
	student FIT VUT Brno

Re: PCM Rate Plugin

[Jaroslav Kysela]

On Fri, 12 Apr 2002, Kasparek Tomas wrote:

> On Thu, 11 Apr 2002, Takashi Iwai wrote:
> 
> > Hi Kasparek,
> >
> > > But for native ALSA recoding on frequency other that defined in card ends
> > > with "arecord" saying everything is fine, but created file contains just
> > > header. My driver is requested to capture on some near rate in this case.
> >
> > well, then it's a bug of alsa-lib.
> > could you explain the symptom more precisely?
> 
> I have solved this yet. Original behavior (using "pcm.default") was:
> 
> - using rate supported by card -> mono and stereo capture works
> 
> - using non-standard rate -> just stereo works (that is native for the UDA
>   chip), for Mono "arecod" produces just 44bytes of header.

It should work in both cases. I suspect for a bug in alsa-lib. Can you 
trigger this bug also in snd-dummy driver? Can you send me modified dummy 
driver then?

> Weel, I would like to ask one more question: The chip sipport not only
> 16bit(LE) samples but 18 and 20 bits LE samples too. Would it be hard to
> update ALSA to support these sample sizes? Where should I look for
> informations when trying to get this running?

How are these samples organized? They are stored in 32-bit words or 
something else?

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com

Re: PCM Rate Plugin

[Kasparek Tomas]

On Fri, 12 Apr 2002, Jaroslav Kysela wrote:

> On Fri, 12 Apr 2002, Kasparek Tomas wrote:
>
> > > well, then it's a bug of alsa-lib.
> > > could you explain the symptom more precisely?
> >
> > I have solved this yet. Original behavior (using "pcm.default") was:
> >
> > - using rate supported by card -> mono and stereo capture works
> >
> > - using non-standard rate -> just stereo works (that is native for the UDA
> >   chip), for Mono "arecod" produces just 44bytes of header.
>
> It should work in both cases. I suspect for a bug in alsa-lib. Can you
> trigger this bug also in snd-dummy driver? Can you send me modified dummy
> driver then?

I will try it.

> > Weel, I would like to ask one more question: The chip sipport not only
> > 16bit(LE) samples but 18 and 20 bits LE samples too. Would it be hard to
> > update ALSA to support these sample sizes? Where should I look for
> > informations when trying to get this running?
>
> How are these samples organized? They are stored in 32-bit words or
> something else?

I did't tried yet, but from the documentation I suppose they are stored in
18/20-bit words. All transfer is done via serial line, so after DMA
transfer you probably get these 18/20bit words without any padding.

I will try this too and send results.

Bye

--

	Tomas Kasparek (sioux, xkaspa06)
 	 tomas.kasparek@[seznam.cz,volny.cz]
	 linux@fit.vutbr.cz
	student FIT VUT Brno