alsa-utils-0.9.0rc4

alsa-utils-0.9.0rc4

[Wolfgang Teichmann]

[-- Attachment #1: Type: text/plain, Size: 208 bytes --]

Hallo,

I have a problem compiling alsa-utils-0.9.0rc4:

RedHat 8.0

./configure

creating cache ./config.cache
configure: error: can not find install-sh or install.sh in . ./.. ./../..

Any hint?

-Wolfgang

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3447 bytes --]

Re: alsa-utils-0.9.0rc4

[Matthias Saou]

Once upon a time, Wolfgang wrote :

> I have a problem compiling alsa-utils-0.9.0rc4:
> 
> RedHat 8.0
> 
> ./configure
> 
> creating cache ./config.cache
> configure: error: can not find install-sh or install.sh in . ./.. ./../..
> 
> Any hint?

I see the same problem. In the tarball, there are links where scripts
should have been copied. To fix in rc5 too?

install-sh -> /usr/share/automake/install-sh
missing -> /usr/share/automake/missing
mkinstalldirs -> /usr/share/automake/mkinstalldirs

So compilation will work _only_ if you have automake installed.

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Red Hat Linux release 7.3 (Valhalla) running Linux kernel 2.4.18-10acpi
Load : 1.32 0.46 0.19


-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en

Re: alsa-utils-0.9.0rc4

[Takashi Iwai]

At Wed, 23 Oct 2002 16:50:03 +0200,
Matthias Saou wrote:
> 
> Once upon a time, Wolfgang wrote :
> 
> > I have a problem compiling alsa-utils-0.9.0rc4:
> > 
> > RedHat 8.0
> > 
> > ./configure
> > 
> > creating cache ./config.cache
> > configure: error: can not find install-sh or install.sh in . ./.. ./../..
> > 
> > Any hint?
> 
> I see the same problem. In the tarball, there are links where scripts
> should have been copied. To fix in rc5 too?
 
yes.  --copy option for automake was missing in cvscompile.
should be fixed.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en

rates and frame-based formats

[Guilhem Tardy]

Hi,

There are some frame-based formats defined in asound.h and pcm.h. For full-rate
GSM, frames are 260 bits every 20 ms. So my question is:
In such a case, should an application use (and the driver define) a rate of
50Hz, or the standard 8000Hz?

Thanks,
Guilhem.


__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/


-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en

Re: rates and frame-based formats

[Jaroslav Kysela]

On Wed, 23 Oct 2002, Guilhem Tardy wrote:

> Hi,
> 
> There are some frame-based formats defined in asound.h and pcm.h. For full-rate
> GSM, frames are 260 bits every 20 ms. So my question is:
> In such a case, should an application use (and the driver define) a rate of
> 50Hz, or the standard 8000Hz?

This is very good question. We should make a decision. If we use 50Hz, we 
can easily calculate frames per second, otherwise we have to translate 
sampling rate to physical rate.. But it's the only good point which I see.

Also, the situation is very easy for GSM where the sampling rate is fixed, 
but what about some variable rate compressions with different sampling 
rate / physical rate ratio?

						Jaroslav

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



-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en

Re: rates and frame-based formats

[Guilhem Tardy]

> This is very good question. We should make a decision. If we use 50Hz, we 
> can easily calculate frames per second, otherwise we have to translate 
> sampling rate to physical rate.. But it's the only good point which I see.

I am not sure how you'd translate between the two? To me, one option is to
define the number of samples per frame (which is 1 for all commonly used
formats), and then:
physical rate = sampling rate / samples per frame

Is the rate actually used for scheduling purposes? Because otherwise there's no
need for something like "physical rate".

> Also, the situation is very easy for GSM where the sampling rate is fixed, 
> but what about some variable rate compressions with different sampling 
> rate / physical rate ratio?

Although variable rate compressions can be an issue, all formats that I can
think of have a specific number of samples per frame (if you allow the fact
that MPEG-1 layer I, II and III are different formats).

Usually, a finite number of physical widths per frame translate into their
corresponding bit rates. But MPEG-1 layer III seems to be another beast by only
defining an average bit rate.

Guilhem.


__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/


-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en