Re: underruns and strange code in pcm_rate.c

[Takashi Iwai <tiwai@suse.de>]

At Fri, 01 Feb 2008 09:18:46 -0600,
Timur Tabi wrote:
> 
> Takashi Iwai wrote:
> 
> > An ML archive has also a URL :)
> > An advantage of ML is that it can involve developers more easily.
> 
> I'm not saying that the developers should use BTS instead of ML.  I'm saying 
> that if it really is a bug in ALSA, I'd like to have formal recognition of that. 
>   A entry in BTS would qualify.  I strewn-out discussion on a mailing list has 
> too low of a signal-to-noise ratio to be useful to the PHBs.

Do as you like.  I just give you advise that you have a better chance
here for debugging such a problem than on BTS.  BTS are full of ****
bug reports that one can't handle sanely.

> > OK, now the question is in which condition this happens...
> 
> I'll try to get an exact testcase, but I think it's pretty much always with 
> "mplayer -ao oss".
> 
> > Could you rewrite snd-dummy driver to behave like your driver?
> 
> Uh, are you kidding?

I'm serious.

>  My driver is an ASoC driver.  How am I supposed to make a 
> dummy driver "behave" like my driver?  My driver isn't doing anything unusual.

It's unusual that this problem happens only on your system.
And, your driver isn't portable to other systems, so we have to find
out the way to reproduce the bug.

> > As mentionted, it's important to get the environment to reproduce the
> > problem reliably independent on hardwares.
> 
> I understand that, but I don't see how I can do that.

Simply make snd_pcm_hardware fields to match with yours so that 
we get the identical hardware constraints.  You see many examples in
the code.


Takashi