alsa-lib resamplers broken.

alsa-lib resamplers broken.

[James Courtier-Dutton]

Hi,

If I use the "front" device name, and select a rate of 48000, I get 
sound output. (snd-intel8x0)
If I use the "front" device name, and select a rate of 44100, It replies 
saying 44100 is not availiable, try 48000 instead!

As the "front" device is a plug device, alsa-lib should automatically 
resample 44100 to 48000 instead of rejecting 44100.

This is only a problem when the alsa-lib resamplers are needed.
If the card hardware supports 48000 and 44100, it works fine, but as the 
snd-intel8x0 only supports 1 rate, the alsa-lib resamplers should act 
but fail.

Please help

Cheers
James


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: alsa-lib resamplers broken.

[Jaroslav Kysela]

On Wed, 17 Dec 2003, James Courtier-Dutton wrote:

> Hi,
> 
> If I use the "front" device name, and select a rate of 48000, I get 
> sound output. (snd-intel8x0)
> If I use the "front" device name, and select a rate of 44100, It replies 
> saying 44100 is not availiable, try 48000 instead!
> 
> As the "front" device is a plug device, alsa-lib should automatically 
> resample 44100 to 48000 instead of rejecting 44100.

"front" is _NOT_ a plug device. If you want to use front as plug device, 
use "plug:front".

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: alsa-lib resamplers broken.

[James Courtier-Dutton]

Jaroslav Kysela wrote:
> On Wed, 17 Dec 2003, James Courtier-Dutton wrote:
> 
> 
>>Hi,
>>
>>If I use the "front" device name, and select a rate of 48000, I get 
>>sound output. (snd-intel8x0)
>>If I use the "front" device name, and select a rate of 44100, It replies 
>>saying 44100 is not availiable, try 48000 instead!
>>
>>As the "front" device is a plug device, alsa-lib should automatically 
>>resample 44100 to 48000 instead of rejecting 44100.
> 
> 
> "front" is _NOT_ a plug device. If you want to use front as plug device, 
> use "plug:front".
> 
> 						Jaroslav

Ooh! Interesting. So it is only a "plug" device, if it has "plug:" 
before it. So the following are all non-plug devices?
"front", "rear", "center-lfe", "surround40", "surround51" etc.

Plug devices: -
dmix, dsnoop and anything with "plug:" before it.

Cheers
James



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: alsa-lib resamplers broken.

[Frank Barknecht]

Hallo,
James Courtier-Dutton hat gesagt: // James Courtier-Dutton wrote:

> Ooh! Interesting. So it is only a "plug" device, if it has "plug:" 
> before it. So the following are all non-plug devices?
> "front", "rear", "center-lfe", "surround40", "surround51" etc.
> 
> Plug devices: -
> dmix, dsnoop and anything with "plug:" before it.

To be correct: "dmix" is not a plug device, but "plug:dmix" is.  You
can see the exact definitions with 

$ aplay -L 2>&1 | less

For example, normally "default" is defined to be a plug device:

 default {
        type plug # <<< plug!
        slave.pcm {
 ...
 }

Also "plughw" is one, "plug" of course and everything, that has "type
plug" in it.

ciao
-- 
 Frank Barknecht                               _ ______footils.org__


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: alsa-lib resamplers broken.

[Jaroslav Kysela]

On Wed, 17 Dec 2003, James Courtier-Dutton wrote:

> Jaroslav Kysela wrote:
> > On Wed, 17 Dec 2003, James Courtier-Dutton wrote:
> > 
> > 
> >>Hi,
> >>
> >>If I use the "front" device name, and select a rate of 48000, I get 
> >>sound output. (snd-intel8x0)
> >>If I use the "front" device name, and select a rate of 44100, It replies 
> >>saying 44100 is not availiable, try 48000 instead!
> >>
> >>As the "front" device is a plug device, alsa-lib should automatically 
> >>resample 44100 to 48000 instead of rejecting 44100.
> > 
> > 
> > "front" is _NOT_ a plug device. If you want to use front as plug device, 
> > use "plug:front".
> > 
> > 						Jaroslav
> 
> Ooh! Interesting. So it is only a "plug" device, if it has "plug:" 
> before it. So the following are all non-plug devices?
> "front", "rear", "center-lfe", "surround40", "surround51" etc.
> 
> Plug devices: -
> dmix, dsnoop and anything with "plug:" before it.

No. The only exception is the "plughw" device. Other devices must have 
"plug:" prefix to allow all configurations (and yes, "plug:hw" is equal to 
"plughw"). In other words, you have to say explicitly that you want an 
access with additional stream conversions.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

A bug in intel8x0.c

[freeman.liu]

Hi, guy,
   
    I'm sure I found a bug in intel8x0.c.
   
    At the end of the function snd_intel8x0_codec_semaphore. If we 
couldn't get the semaphore in
1 ms, we'll reset the register and return EBUSY. But to reset the 
register, we should do a
    iaputword ( chip, 0, 0 ), according to the datasheet, write any 
value the this register will reset the
register.
    But in the code, what we did is iagetword ( chip, 0 ). This bug 
hadn't be exclosed because this code
path had never been reached, for the semaphore error often means a 
hardware error, which is very
rare.
    So, is there anybody who can modify this ?


    Freeman




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: A bug in intel8x0.c

[Clemens Ladisch]

freeman.liu wrote:
> At the end of the function snd_intel8x0_codec_semaphore. If we
> couldn't get the semaphore in 1 ms, we'll reset the register and
> return EBUSY. But to reset the register, we should do a
> iaputword ( chip, 0, 0 ), according to the datasheet, write any
> value the this register will reset the register.
> But in the code, what we did is iagetword ( chip, 0 ).

At that point, we don't want to reset the semaphore but to access a
dummy AC'97 register so that the semaphore flag is cleared even if we
actually got the semaphore (from the igetbyte in the printk).  (The
iagetword/iaputword functions access AC'97 registers, not ICH
registers.)


HTH
Clemens




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: A bug in intel8x0.c

[freeman.liu]

Clemens Ladisch wrote:

>freeman.liu wrote:
>  
>
>>At the end of the function snd_intel8x0_codec_semaphore. If we
>>couldn't get the semaphore in 1 ms, we'll reset the register and
>>return EBUSY. But to reset the register, we should do a
>>iaputword ( chip, 0, 0 ), according to the datasheet, write any
>>value the this register will reset the register.
>>But in the code, what we did is iagetword ( chip, 0 ).
>>    
>>
>
>At that point, we don't want to reset the semaphore but to access a
>dummy AC'97 register so that the semaphore flag is cleared even if we
>actually got the semaphore (from the igetbyte in the printk).  (The
>iagetword/iaputword functions access AC'97 registers, not ICH
>registers.)
>
>  
>
Semaphore is clear when a writing operation is finished, and it' done 
automatically
by the hardware. I think you have misunstandard the code, the printk is 
just print
out the sema register and global-status register for debug.

Look at the comment after the iagetword. And read the ac97 specification.
Read the ac97 reset register will return the value. write any value to 
it will reset the
ac97 registers. When code run to this point there must be some error in 
the hardware,
so we need a reset.

>HTH
>Clemens
>
>
>  
>


-- 

	Best regards
	Freeman Liu




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn