[PATCH] configure prob with MDK82 kernel

[PATCH] configure prob with MDK82 kernel

[Tom Prado]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 274 bytes --]

I had a problem running configure against the Linux Mandrake 8.2 UP 
kernel.  It would fail when trying to determine the kernel version.  This 
patch for rc1 adds the needed includes so that linux/rhconfig.h can be 
found when configure checks for the kernel version.

Tom


[-- Attachment #2: Type: TEXT/PLAIN, Size: 306 bytes --]

--- alsa-driver-0.9.0rc1/configure.in	Wed Apr 24 11:29:55 2002
+++ alsa-driver-0.9.0rc1.tom/configure.in	Wed Apr 24 14:16:31 2002
@@ -82,6 +82,7 @@ EOF
   exit 1
 fi
 AC_CACHE_VAL(kaversion,
+CFLAGS="$CFLAGS -I$CONFIG_SND_KERNELDIR/include"
 [AC_TRY_RUN([
 #include <stdio.h>
 #include <ctype.h>

Re: [PATCH] configure prob with MDK82 kernel

[Thierry Vignaud]

Tom Prado <tprado@charter.net> writes:

> I had a problem running configure against the Linux Mandrake 8.2 UP
> kernel.  It would fail when trying to determine the kernel version.
> This patch for rc1 adds the needed includes so that linux/rhconfig.h
> can be found when configure checks for the kernel version.

use a 2.4.18-10mdk kernel and above: we've updated alsa from 0.5 upto
0.9 in 10mdk.
note that this is a cooker kernel, not a mdk8.2 release kernel.
-- 
"il a ete brule au 28e degre" (the naheulbeuk witch)
"c curieux, gcc fonctionne" (gwenole)

Re: [PATCH] configure prob with MDK82 kernel

[Tom Prado]

Thanks!  I try to run the release versions of the kernel so third party 
apps (like vmware for instance) will be sure to work.  I've 
attached the patch inline this time.  It's only one line to be added to 
configure.in.  alsa 0.5.12 had this in it, it's gone from 0.9.0rc1.

--- alsa-driver-0.9.0rc1/configure.in	Wed Apr 24 11:29:55 2002
+++ alsa-driver-0.9.0rc1.tom/configure.in	Wed Apr 24 14:16:31 2002
@@ -82,6 +82,7 @@ EOF
   exit 1
 fi
 AC_CACHE_VAL(kaversion,
+CFLAGS="$CFLAGS -I$CONFIG_SND_KERNELDIR/include"
 [AC_TRY_RUN([
 #include <stdio.h>
 #include <ctype.h>

On Wed, 24 Apr 2002, Thierry Vignaud wrote:

> Tom Prado <tprado@charter.net> writes:
> 
> > I had a problem running configure against the Linux Mandrake 8.2 UP
> > kernel.  It would fail when trying to determine the kernel version.
> > This patch for rc1 adds the needed includes so that linux/rhconfig.h
> > can be found when configure checks for the kernel version.
> 
> use a 2.4.18-10mdk kernel and above: we've updated alsa from 0.5 upto
> 0.9 in 10mdk.
> note that this is a cooker kernel, not a mdk8.2 release kernel.
> 

-- 

BrookTree

[Bill Merrill]

How's everyone doing? Another student and I are planning on implementing
some new sound-card driver support under Linux.  We both possess an ATI TV
Wonder, so we were interested in implementing driver support for the
BrookTree bt878 chipset.  We have OS experience, but have not had experience
implementing sound drivers.

If anyone has some good documentation that could provide some help in
getting started, we'd greatly appreciate it.  The online documentation
hasn't given us much to go with, so we're open for any info someone is
willing to give is.

Thanks alot for reading

- Bill Merrill & Scott Paffrat

----- Original Message -----
From: "Tom Prado" <tprado@charter.net>
To: <alsa-devel@lists.sourceforge.net>
Sent: Wednesday, April 24, 2002 1:47 PM
Subject: Re: [Alsa-devel] [PATCH] configure prob with MDK82 kernel


> Thanks!  I try to run the release versions of the kernel so third party
> apps (like vmware for instance) will be sure to work.  I've
> attached the patch inline this time.  It's only one line to be added to
> configure.in.  alsa 0.5.12 had this in it, it's gone from 0.9.0rc1.
>
> --- alsa-driver-0.9.0rc1/configure.in Wed Apr 24 11:29:55 2002
> +++ alsa-driver-0.9.0rc1.tom/configure.in Wed Apr 24 14:16:31 2002
> @@ -82,6 +82,7 @@ EOF
>    exit 1
>  fi
>  AC_CACHE_VAL(kaversion,
> +CFLAGS="$CFLAGS -I$CONFIG_SND_KERNELDIR/include"
>  [AC_TRY_RUN([
>  #include <stdio.h>
>  #include <ctype.h>
>
> On Wed, 24 Apr 2002, Thierry Vignaud wrote:
>
> > Tom Prado <tprado@charter.net> writes:
> >
> > > I had a problem running configure against the Linux Mandrake 8.2 UP
> > > kernel.  It would fail when trying to determine the kernel version.
> > > This patch for rc1 adds the needed includes so that linux/rhconfig.h
> > > can be found when configure checks for the kernel version.
> >
> > use a 2.4.18-10mdk kernel and above: we've updated alsa from 0.5 upto
> > 0.9 in 10mdk.
> > note that this is a cooker kernel, not a mdk8.2 release kernel.
> >
>
> --
>
>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel


_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: BrookTree

[Ville Syrjälä]

On Thu, Apr 25, 2002 at 01:05:29AM -0700, Bill Merrill wrote:
> How's everyone doing? Another student and I are planning on implementing
> some new sound-card driver support under Linux.  We both possess an ATI TV
> Wonder, so we were interested in implementing driver support for the
> BrookTree bt878 chipset.  We have OS experience, but have not had experience
> implementing sound drivers.
> 
> If anyone has some good documentation that could provide some help in
> getting started, we'd greatly appreciate it.  The online documentation
> hasn't given us much to go with, so we're open for any info someone is
> willing to give is.

There is an OSS/free driver for bt878. It's written by Gerd Knorr
<kraxel@bytesex.org>. Maybe you should ask him.

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

ALSA sequencer input buffer

[Richard Bown]

Hi,

Is it correct that an app should have to snd_seq_drop_input_buffer() every
so often when reading events in via snd_seq_event_input()?

If I don't drop the input buffer periodically then the input buffer appears
eventually to clog up - only allowing a few events through at a time.  Whilst
the number of events received by the app becomes severely limited it still
just about continues to work.  Is there an easy explanation for this behaviour?

Am I doing the right thing in dropping the buffer?  It certainly appears to
fix the problem.

Cheers,
Richard
-- 
http://www.all-day-breakfast.com/rosegarden
http://www.bownie.com

Re: ALSA sequencer input buffer

[Takashi Iwai]

Hi Richard,

At Thu, 25 Apr 2002 13:08:15 +0100,
Richard Bown wrote:
> 
> Hi,
> 
> Is it correct that an app should have to snd_seq_drop_input_buffer() every
> so often when reading events in via snd_seq_event_input()?
> 
> If I don't drop the input buffer periodically then the input buffer appears
> eventually to clog up - only allowing a few events through at a time.  Whilst
> the number of events received by the app becomes severely limited it still
> just about continues to work.  Is there an easy explanation for this behaviour?

no, you shouldn't drop input events.  otherwise the input events will
be really lost.

if the events are on input buffer (this can be checked by
snd_seq_event_input_pending), then process all these events in a
loop.  (i guess you call snd_seq_event_input only once in poll
handler.)

on blocking mode, a typical code would be like this.

	while (snd_seq_event_input_pending(handle, 1) > 0) {
		if (snd_seq_event_input(handle, &ev) < 0)
			error;
		do_something;
	}

this will feed events from the sequencer core to the buffer when the
buffer becomes empty.  please note that snd_seq_event_input_pending()
won't block even if no events exist but returns immediately.

on non-blocking mode, you can use simply snd_seq_event_input() loop.

	while (snd_seq_event_input(handle, &ev) >= 0) {
		do_something;
	}


Takashi

Re: ALSA sequencer input buffer

[Richard Bown]

Takashi Iwai wrote:

> no, you shouldn't drop input events.  otherwise the input events will
> be really lost.

Oh ok, from your code examples I see that I was implementing a blocking
model for a non-blocking port.  Following the second example seems to have
fixed it without the need to drop any events.

Thanks Takashi.

R