hdsp driver

hdsp driver

[Paul Davis]

i haven't had time today to get the patch for the hdsp ready. however,
the new source works here (i have some CVS sync issues). i'll get it
out to the list on monday (i'm gone for the weekend).


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: hdsp driver

[Takashi Iwai]

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

Hi Paul,

At Thu, 27 Feb 2003 13:43:34 -0500,
Paul Davis wrote:
> 
> i haven't had time today to get the patch for the hdsp ready. however,
> the new source works here (i have some CVS sync issues). i'll get it
> out to the list on monday (i'm gone for the weekend).

could you check the attached patch (to the current cvs version) for
rme9652 and hdsp?

it will replace the memory allocation using the new snd-page-alloc
module instead of snd-hammerfall-mem.

although the former doesn't allocate the buffer in advance by checking
the pci id, but it will preserve the buffers at alsasound stop or
restart operations just like the latter does.


Takashi

[-- Attachment #2: rme-mem-new.dif --]
[-- Type: application/octet-stream, Size: 8406 bytes --]

Index: alsa-kernel/scripts/Modules.dep
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/scripts/Modules.dep,v
retrieving revision 1.16
diff -u -r1.16 Modules.dep
--- alsa-kernel/scripts/Modules.dep	25 Feb 2003 14:55:50 -0000	1.16
+++ alsa-kernel/scripts/Modules.dep	27 Feb 2003 14:08:14 -0000
@@ -187,9 +187,8 @@
 |snd-nm256 snd-pcm snd-ac97-codec
 
 %dir linux/sound/pci/rme9652
-snd-hammerfall-mem
-|snd-rme9652 snd-pcm snd-hammerfall-mem
-|snd-hdsp snd-pcm snd-hammerfall-mem
+|snd-rme9652 snd-pcm
+|snd-hdsp snd-pcm snd-rawmidi
 
 %dir linux/sound/pci/trident
 snd-trident-synth @if_sequencer snd-seq-midi-emul snd-ainstr-simple
Index: alsa-kernel/pci/rme9652/Makefile
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/pci/rme9652/Makefile,v
retrieving revision 1.7
diff -u -r1.7 Makefile
--- alsa-kernel/pci/rme9652/Makefile	10 Feb 2003 09:02:18 -0000	1.7
+++ alsa-kernel/pci/rme9652/Makefile	26 Feb 2003 15:52:21 -0000
@@ -3,10 +3,9 @@
 # Copyright (c) 2001 by Jaroslav Kysela <perex@suse.cz>
 #
 
-snd-hammerfall-mem-objs := hammerfall_mem.o
 snd-rme9652-objs := rme9652.o
 snd-hdsp-objs := hdsp.o
 
 # Toplevel Module Dependency
-obj-$(CONFIG_SND_RME9652) += snd-rme9652.o snd-hammerfall-mem.o
-obj-$(CONFIG_SND_HDSP) += snd-hdsp.o snd-hammerfall-mem.o
+obj-$(CONFIG_SND_RME9652) += snd-rme9652.o
+obj-$(CONFIG_SND_HDSP) += snd-hdsp.o
Index: alsa-kernel/pci/rme9652/hammerfall_mem.h
===================================================================
RCS file: alsa-kernel/pci/rme9652/hammerfall_mem.h
diff -N alsa-kernel/pci/rme9652/hammerfall_mem.h
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ alsa-kernel/pci/rme9652/hammerfall_mem.h	28 Feb 2003 13:28:18 -0000
@@ -0,0 +1,35 @@
+/*
+ */
+
+#include <sound/memalloc.h>
+
+static void *snd_hammerfall_get_buffer(struct pci_dev *pci, size_t size, dma_addr_t *addrp, int capture)
+{
+	struct snd_dma_device pdev;
+	struct snd_dma_buffer dmbuf;
+
+	snd_dma_device_pci(&pdev, pci, capture);
+	memset(&dmbuf, 0, sizeof(dmbuf));
+	if (! snd_dma_get_reserved(&pdev, &dmbuf)) {
+		if (snd_dma_alloc_pages(&pdev, size, &dmbuf) < 0)
+			return NULL;
+		snd_dma_set_reserved(&pdev, &dmbuf);
+	}
+	*addrp = dmbuf.addr;
+	return dmbuf.area;
+}
+
+static void snd_hammerfall_free_buffer(struct pci_dev *pci, int capture)
+{
+	struct snd_dma_device dev;
+	snd_dma_device_pci(&dev, pci, capture);
+	snd_dma_set_reserved(&dev, NULL);
+}
+
+static void snd_hammerfall_release_buffer(struct pci_dev *pci, int capture)
+{
+	struct snd_dma_device dev;
+	snd_dma_device_pci(&dev, pci, capture);
+	snd_dma_free_reserved(&dev);
+}
+
Index: alsa-kernel/pci/rme9652/hdsp.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/pci/rme9652/hdsp.c,v
retrieving revision 1.21
diff -u -r1.21 hdsp.c
--- alsa-kernel/pci/rme9652/hdsp.c	14 Feb 2003 09:33:44 -0000	1.21
+++ alsa-kernel/pci/rme9652/hdsp.c	26 Feb 2003 15:52:11 -0000
@@ -405,12 +405,6 @@
 	-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1
 };
 
-#define HDSP_PREALLOCATE_MEMORY	/* via module snd-hdsp_mem */
-
-#ifdef HDSP_PREALLOCATE_MEMORY
-extern void *snd_hammerfall_get_buffer(struct pci_dev *, dma_addr_t *dmaaddr);
-extern void snd_hammerfall_free_buffer(struct pci_dev *, void *ptr);
-#endif
 
 static struct pci_device_id snd_hdsp_ids[] __devinitdata = {
 	{
@@ -2084,28 +2078,16 @@
 		snd_info_set_text_ops(entry, hdsp, snd_hdsp_proc_read);
 }
 
+#include "hammerfall_mem.h"
+
 static void snd_hdsp_free_buffers(hdsp_t *hdsp)
 {
 	if (hdsp->capture_buffer_unaligned) {
-#ifndef HDSP_PREALLOCATE_MEMORY
-		snd_free_pci_pages(hdsp->pci,
-				   HDSP_DMA_AREA_BYTES,
-				   hdsp->capture_buffer_unaligned,
-				   hdsp->capture_buffer_addr);
-#else
-		snd_hammerfall_free_buffer(hdsp->pci, hdsp->capture_buffer_unaligned);
-#endif
+		snd_hammerfall_release_buffer(hdsp->pci, 1);
 	}
 
 	if (hdsp->playback_buffer_unaligned) {
-#ifndef HDSP_PREALLOCATE_MEMORY
-		snd_free_pci_pages(hdsp->pci,
-				   HDSP_DMA_AREA_BYTES,
-				   hdsp->playback_buffer_unaligned,
-				   hdsp->playback_buffer_addr);
-#else
-		snd_hammerfall_free_buffer(hdsp->pci, hdsp->playback_buffer_unaligned);
-#endif
+		snd_hammerfall_release_buffer(hdsp->pci, 0);
 	}
 }
 
@@ -2115,29 +2097,14 @@
 	dma_addr_t pb_addr, cb_addr;
 	unsigned long pb_bus, cb_bus;
 
-#ifndef HDSP_PREALLOCATE_MEMORY
-	cb = snd_malloc_pci_pages(hdsp->pci, HDSP_DMA_AREA_BYTES, &cb_addr);
-	pb = snd_malloc_pci_pages(hdsp->pci, HDSP_DMA_AREA_BYTES, &pb_addr);
-#else
-	cb = snd_hammerfall_get_buffer(hdsp->pci, &cb_addr);
-	pb = snd_hammerfall_get_buffer(hdsp->pci, &pb_addr);
-#endif
+	pb = snd_hammerfall_get_buffer(hdsp->pci, HDSP_DMA_AREA_BYTES, &pb_addr, 0);
+	cb = snd_hammerfall_get_buffer(hdsp->pci, HDSP_DMA_AREA_BYTES, &cb_addr, 1);
 
 	if (cb == 0 || pb == 0) {
-		if (cb) {
-#ifdef HDSP_PREALLOCATE_MEMORY
-			snd_hammerfall_free_buffer(hdsp->pci, cb);
-#else
-			snd_free_pci_pages(hdsp->pci, HDSP_DMA_AREA_BYTES, cb, cb_addr);
-#endif
-		}
-		if (pb) {
-#ifdef HDSP_PREALLOCATE_MEMORY
-			snd_hammerfall_free_buffer(hdsp->pci, pb);
-#else
-			snd_free_pci_pages(hdsp->pci, HDSP_DMA_AREA_BYTES, pb, pb_addr);
-#endif
-		}
+		if (pb)
+			snd_hammerfall_free_buffer(hdsp->pci, 0);
+		if (cb)
+			snd_hammerfall_free_buffer(hdsp->pci, 1);
 
 		printk(KERN_ERR "%s: no buffers available\n", hdsp->card_name);
 		return -ENOMEM;
Index: alsa-kernel/pci/rme9652/rme9652.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/pci/rme9652/rme9652.c,v
retrieving revision 1.27
diff -u -r1.27 rme9652.c
--- alsa-kernel/pci/rme9652/rme9652.c	3 Feb 2003 09:48:44 -0000	1.27
+++ alsa-kernel/pci/rme9652/rme9652.c	26 Feb 2003 15:52:04 -0000
@@ -306,12 +306,6 @@
 	-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1
 };
 
-#define RME9652_PREALLOCATE_MEMORY	/* via module snd-hammerfall-mem */
-
-#ifdef RME9652_PREALLOCATE_MEMORY
-extern void *snd_hammerfall_get_buffer(struct pci_dev *, dma_addr_t *dmaaddr);
-extern void snd_hammerfall_free_buffer(struct pci_dev *, void *ptr);
-#endif
 
 static struct pci_device_id snd_rme9652_ids[] __devinitdata = {
 	{
@@ -1807,28 +1801,16 @@
 		snd_info_set_text_ops(entry, rme9652, snd_rme9652_proc_read);
 }
 
+#include "hammerfall_mem.h"
+
 static void snd_rme9652_free_buffers(rme9652_t *rme9652)
 {
 	if (rme9652->capture_buffer_unaligned) {
-#ifndef RME9652_PREALLOCATE_MEMORY
-		snd_free_pci_pages(rme9652->pci,
-				   RME9652_DMA_AREA_BYTES,
-				   rme9652->capture_buffer_unaligned,
-				   rme9652->capture_buffer_addr);
-#else
-		snd_hammerfall_free_buffer(rme9652->pci, rme9652->capture_buffer_unaligned);
-#endif
+		snd_hammerfall_release_buffer(rme9652->pci, 1);
 	}
 
 	if (rme9652->playback_buffer_unaligned) {
-#ifndef RME9652_PREALLOCATE_MEMORY
-		snd_free_pci_pages(rme9652->pci,
-				   RME9652_DMA_AREA_BYTES,
-				   rme9652->playback_buffer_unaligned,
-				   rme9652->playback_buffer_addr);
-#else
-		snd_hammerfall_free_buffer(rme9652->pci, rme9652->playback_buffer_unaligned);
-#endif
+		snd_hammerfall_release_buffer(rme9652->pci, 0);
 	}
 }
 
@@ -1855,29 +1837,14 @@
 	dma_addr_t pb_addr, cb_addr;
 	unsigned long pb_bus, cb_bus;
 
-#ifndef RME9652_PREALLOCATE_MEMORY
-	cb = snd_malloc_pci_pages(rme9652->pci, RME9652_DMA_AREA_BYTES, &cb_addr);
-	pb = snd_malloc_pci_pages(rme9652->pci, RME9652_DMA_AREA_BYTES, &pb_addr);
-#else
-	cb = snd_hammerfall_get_buffer(rme9652->pci, &cb_addr);
-	pb = snd_hammerfall_get_buffer(rme9652->pci, &pb_addr);
-#endif
+	pb = snd_hammerfall_get_buffer(rme9652->pci, RME9652_DMA_AREA_BYTES, &pb_addr, 0);
+	cb = snd_hammerfall_get_buffer(rme9652->pci, RME9652_DMA_AREA_BYTES, &cb_addr, 1);
 
 	if (cb == 0 || pb == 0) {
-		if (cb) {
-#ifdef RME9652_PREALLOCATE_MEMORY
-			snd_hammerfall_free_buffer(rme9652->pci, cb);
-#else
-			snd_free_pci_pages(rme9652->pci, RME9652_DMA_AREA_BYTES, cb, cb_addr);
-#endif
-		}
-		if (pb) {
-#ifdef RME9652_PREALLOCATE_MEMORY
-			snd_hammerfall_free_buffer(rme9652->pci, pb);
-#else
-			snd_free_pci_pages(rme9652->pci, RME9652_DMA_AREA_BYTES, pb, pb_addr);
-#endif
-		}
+		if (pb)
+			snd_hammerfall_free_buffer(rme9652->pci, 0);
+		if (cb)
+			snd_hammerfall_free_buffer(rme9652->pci, 1);
 
 		printk(KERN_ERR "%s: no buffers available\n", rme9652->card_name);
 		return -ENOMEM;

Re: hdsp driver

[Thomas Charbonnel]

On Thu, 2003-02-27 at 19:43, Paul Davis wrote:
> i haven't had time today to get the patch for the hdsp ready. however,
> the new source works here (i have some CVS sync issues). i'll get it
> out to the list on monday (i'm gone for the weekend).
> 
Did you sort out the rms register issue ? I'm currently implementing the
metering part of HDSPMixer and the rms values returned are obviously
bogus.

Thomas




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

[PATCH] HDSP rms and peak registers correct offsets (was: Re: hdsp driver)

[Thomas Charbonnel]

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

On Sun, 2003-03-02 at 21:24, Thomas Charbonnel wrote:
> On Thu, 2003-02-27 at 19:43, Paul Davis wrote:
> > i haven't had time today to get the patch for the hdsp ready. however,
> > the new source works here (i have some CVS sync issues). i'll get it
> > out to the list on monday (i'm gone for the weekend).
> > 
> Did you sort out the rms register issue ? I'm currently implementing the
> metering part of HDSPMixer and the rms values returned are obviously
> bogus.
> 
> Thomas

Ok, I sorted it out myself, the offsets for the rms and peak registers
were wrong. Sorry Paul, I could have seen this much earlier if I had
done more extensive tests: I kept on testing inputs 1 and 2 while the
input rms offset pointed on input 3... :-\

The correct offsets can be found in the attached patch.

Thomas


[-- Attachment #2: hdsp_registers.patch --]
[-- Type: text/plain, Size: 606 bytes --]

--- hdsp.c.orig	2003-03-03 00:30:46.000000000 +0100
+++ hdsp.c	2003-03-03 00:32:10.000000000 +0100
@@ -123,9 +123,9 @@
 
 #define HDSP_playbackPeakLevel  4096  /* 26 * 32 bit values */
 #define HDSP_inputPeakLevel     4224  /* 26 * 32 bit values */
-#define HDSP_outputPeakLevel    4100  /* 26 * 32 bit values */
+#define HDSP_outputPeakLevel    4096  /* 26 * 32 bit values */
 #define HDSP_playbackRmsLevel   4612  /* 26 * 64 bit values */
-#define HDSP_inputRmsLevel      4884  /* 26 * 64 bit values */
+#define HDSP_inputRmsLevel      4868  /* 26 * 64 bit values */
 
 #define HDSP_IO_EXTENT     5192
 

RE: [PATCH] HDSP rms and peak registers correct offsets (was: Re:hdsp driver)

[Mark Knecht]

Thomas,
   Will this work cover the HDSP 9652 also, or is that different and has to
wait?

Thanks,
Mark

> -----Original Message-----
> From: alsa-devel-admin@lists.sourceforge.net
> [mailto:alsa-devel-admin@lists.sourceforge.net]On Behalf Of Thomas
> Charbonnel
> Sent: Sunday, March 02, 2003 3:43 PM
> To: Paul Davis
> Cc: alsa-devel
> Subject: [PATCH] HDSP rms and peak registers correct offsets (was:
> Re:[Alsa-devel] hdsp driver)
>
>
> On Sun, 2003-03-02 at 21:24, Thomas Charbonnel wrote:
> > On Thu, 2003-02-27 at 19:43, Paul Davis wrote:
> > > i haven't had time today to get the patch for the hdsp ready. however,
> > > the new source works here (i have some CVS sync issues). i'll get it
> > > out to the list on monday (i'm gone for the weekend).
> > >
> > Did you sort out the rms register issue ? I'm currently implementing the
> > metering part of HDSPMixer and the rms values returned are obviously
> > bogus.
> >
> > Thomas
>
> Ok, I sorted it out myself, the offsets for the rms and peak registers
> were wrong. Sorry Paul, I could have seen this much earlier if I had
> done more extensive tests: I kept on testing inputs 1 and 2 while the
> input rms offset pointed on input 3... :-\
>
> The correct offsets can be found in the attached patch.
>
> Thomas
>
>




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

RE: [PATCH] HDSP rms and peak registers correct offsets (was: Re:hdsp driver)

[Thomas Charbonnel]

On Mon, 2003-03-03 at 15:23, Mark Knecht wrote:
> Thomas,
>    Will this work cover the HDSP 9652 also, or is that different and has to
> wait?
> 
> Thanks,
> Mark

No, sorry, I'm afraid you'll have to wait.

Thomas




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: [PATCH] HDSP rms and peak registers correct offsets (was: Re: hdsp driver)

[Thomas Charbonnel]

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

On Mon, 2003-03-03 at 00:43, Thomas Charbonnel wrote:
> The correct offsets can be found in the attached patch.
> 
Err... this wasn't the case.
The attached patch replaces the previous one and enhances it with line
outs metering.

The line outs peak registers were not accessible with the current
driver, so I added code to map them to ctls. The option I took is
mapping all the registers, even the unused ones (i.e. from 19 to 26 on
the Multiface), as those registers are always present, regardless of the
attached box. This approach also avoided ctl index discontinuity. (Due
to the way clts map registers, the ctls mapping the line out registers
(Output Peak) had to have indexes 27 and 29). 
As a side effect this transfers the task of electing relevant registers
to user space applications. (In this perspective I think the 9652
shouldn't look as a digiface from user space, as it has no line outs. It
should have an entry of its own in HDSP_type).

Paul, the meter section of the HDSPMixer is now functional. It helped me
a lot understand how wrong the registers offsets were. I can send you a
copy if you think it can help you implementing 9652 support.

Thomas


[-- Attachment #2: hdsp_regs_lineout.patch --]
[-- Type: text/plain, Size: 1832 bytes --]

--- hdsp.c.orig	2003-03-03 00:30:46.000000000 +0100
+++ hdsp.c	2003-03-03 15:06:38.000000000 +0100
@@ -3,6 +3,7 @@
  *
  *      Copyright (c) 2002  Paul Davis
  *                          Marcus Andersson
+ *                          Thomas Charbonnel
  *
  *   This program is free software; you can redistribute it and/or modify
  *   it under the terms of the GNU General Public License as published by
@@ -123,9 +124,9 @@
 
 #define HDSP_playbackPeakLevel  4096  /* 26 * 32 bit values */
 #define HDSP_inputPeakLevel     4224  /* 26 * 32 bit values */
-#define HDSP_outputPeakLevel    4100  /* 26 * 32 bit values */
+#define HDSP_outputPeakLevel    4352  /* 28 * 32 bit values (26 + 2 line outs) */
 #define HDSP_playbackRmsLevel   4612  /* 26 * 64 bit values */
-#define HDSP_inputRmsLevel      4884  /* 26 * 64 bit values */
+#define HDSP_inputRmsLevel      4868  /* 26 * 64 bit values */
 
 #define HDSP_IO_EXTENT     5192
 
@@ -1864,14 +1865,12 @@
 		if ((err = snd_ctl_add (card, kctl = snd_ctl_new1(&snd_hdsp_playback_mixer, hdsp)))) {
 			return err;
 		}
+	}
+	for (idx = 0; idx < HDSP_MAX_CHANNELS; ++idx) {
 		snd_hdsp_input_peak.index = idx+1;
 		if ((err = snd_ctl_add (card, kctl = snd_ctl_new1(&snd_hdsp_input_peak, hdsp)))) {
 			return err;
 		}
-		snd_hdsp_output_peak.index = idx+1;
-		if ((err = snd_ctl_add (card, kctl = snd_ctl_new1(&snd_hdsp_output_peak, hdsp)))) {
-			return err;
-		}
 		snd_hdsp_playback_peak.index = idx+1;
 		if ((err = snd_ctl_add (card, kctl = snd_ctl_new1(&snd_hdsp_playback_peak, hdsp)))) {
 			return err;
@@ -1885,7 +1884,12 @@
 			return err;
 		}
 	}
-
+	for (idx = 0; idx < HDSP_MAX_CHANNELS + 2 ; ++idx) {
+		snd_hdsp_output_peak.index = idx+1;
+		if ((err = snd_ctl_add (card, kctl = snd_ctl_new1(&snd_hdsp_output_peak, hdsp)))) {
+			return err;
+		}
+	}
 	return 0;
 }
 

RE: [PATCH] HDSP rms and peak registers correct offsets (was:Re:hdsp driver)

[Mark Knecht]

Thomas,
   Thanks for the update. 
Mark

> -----Original Message-----
> From: Thomas Charbonnel [mailto:thomas@undata.org]
> Sent: Monday, March 03, 2003 6:40 AM
> To: Mark Knecht
> Cc: alsa-devel
> Subject: RE: [PATCH] HDSP rms and peak registers correct offsets
> (was:Re:[Alsa-devel] hdsp driver)
> 
> 
> On Mon, 2003-03-03 at 15:23, Mark Knecht wrote:
> > Thomas,
> >    Will this work cover the HDSP 9652 also, or is that 
> different and has to
> > wait?
> > 
> > Thanks,
> > Mark
> 
> No, sorry, I'm afraid you'll have to wait.
> 
> Thomas
> 
> 
> 



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: hdsp driver

[Paul Davis]

>although the former doesn't allocate the buffer in advance by checking
>the pci id, but it will preserve the buffers at alsasound stop or
>restart operations just like the latter does.

so when does it allocate them?


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: hdsp driver

[Takashi Iwai]

At Mon, 03 Mar 2003 11:11:16 -0500,
Paul Davis wrote:
> 
> >although the former doesn't allocate the buffer in advance by checking
> >the pci id, but it will preserve the buffers at alsasound stop or
> >restart operations just like the latter does.
> 
> so when does it allocate them?

when the allocator function (snd_malloc_xxx) is called from the
driver.  so, it wouldn't work exactly like snd-hammerfall-mem, which
allocates by itself without call from the sound drivers.
snd-page-alloc module just "caches" the buffer after the module
unload/reload.

but i don't think this would make so big difference, since the sound
drivers are loaded likely in the early stage, anyway.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: hdsp driver

[Paul Davis]

>At Mon, 03 Mar 2003 11:11:16 -0500,
>Paul Davis wrote:
>> 
>> >although the former doesn't allocate the buffer in advance by checking
>> >the pci id, but it will preserve the buffers at alsasound stop or
>> >restart operations just like the latter does.
>> 
>> so when does it allocate them?
>
>when the allocator function (snd_malloc_xxx) is called from the
>driver.  so, it wouldn't work exactly like snd-hammerfall-mem, which
>allocates by itself without call from the sound drivers.
>snd-page-alloc module just "caches" the buffer after the module
>unload/reload.
>
>but i don't think this would make so big difference, since the sound
>drivers are loaded likely in the early stage, anyway.

they aren't. that's the whole problem. on my old system (148MB of
RAM), allowing fsck to run would prevent memory allocation. i don't
know of any distribution that inserts modules that early. do you?


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: hdsp driver

[Takashi Iwai]

At Mon, 03 Mar 2003 11:37:20 -0500,
Paul Davis wrote:
> 
> >At Mon, 03 Mar 2003 11:11:16 -0500,
> >Paul Davis wrote:
> >> 
> >> >although the former doesn't allocate the buffer in advance by checking
> >> >the pci id, but it will preserve the buffers at alsasound stop or
> >> >restart operations just like the latter does.
> >> 
> >> so when does it allocate them?
> >
> >when the allocator function (snd_malloc_xxx) is called from the
> >driver.  so, it wouldn't work exactly like snd-hammerfall-mem, which
> >allocates by itself without call from the sound drivers.
> >snd-page-alloc module just "caches" the buffer after the module
> >unload/reload.
> >
> >but i don't think this would make so big difference, since the sound
> >drivers are loaded likely in the early stage, anyway.
> 
> they aren't. that's the whole problem. on my old system (148MB of
> RAM), allowing fsck to run would prevent memory allocation. i don't
> know of any distribution that inserts modules that early. do you?

aha, but fsck runs even before snd-hammerfall-mem, doesn't it? (unless
you bulit it in kernel)  otherwise it's dangerous...

now i understood the necessity of the allocation way of
snd-hammerfall-mem.
we can merge the feature but it will be likely after 0.9.0, as long as
the old style works.  i'd like to concentrate on bug fixes now.


ciao,

Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: hdsp driver

[Paul Davis]

>> they aren't. that's the whole problem. on my old system (148MB of
>> RAM), allowing fsck to run would prevent memory allocation. i don't
>> know of any distribution that inserts modules that early. do you?
>
>aha, but fsck runs even before snd-hammerfall-mem, doesn't it? (unless
>you bulit it in kernel)  otherwise it's dangerous...

no. absolutely not. i just added something equivalent to this to
/etc/rc.d/rc.sysinit, right before fsck runs.

   insmod snd-hammerfall-mem

since snd-hammerfall-mem has nothing to do with filesystems on disk,
there is no danger. many other hammerfall users are doing equivalent
things, and its also necessary under windows and macos.

>now i understood the necessity of the allocation way of
>snd-hammerfall-mem.  we can merge the feature but it will be likely
>after 0.9.0, as long as the old style works.  i'd like to concentrate
>on bug fixes now.

as long as you propose to leave snd-hammerfall-mem in
place. otherwise, you will make it impossible for many people to use
their audio interfaces!

--p


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: hdsp driver

[Takashi Iwai]

At Mon, 03 Mar 2003 11:59:56 -0500,
Paul Davis wrote:
> 
> >> they aren't. that's the whole problem. on my old system (148MB of
> >> RAM), allowing fsck to run would prevent memory allocation. i don't
> >> know of any distribution that inserts modules that early. do you?
> >
> >aha, but fsck runs even before snd-hammerfall-mem, doesn't it? (unless
> >you bulit it in kernel)  otherwise it's dangerous...
> 
> no. absolutely not. i just added something equivalent to this to
> /etc/rc.d/rc.sysinit, right before fsck runs.
> 
>    insmod snd-hammerfall-mem
> 
> since snd-hammerfall-mem has nothing to do with filesystems on disk,
> there is no danger.

as long as the snd-hammerfall-mem module itself on the filesystem is 
not broken.  it may happen not rarely if the filesystem crashed just
after (or during) installing the new module files.

> many other hammerfall users are doing equivalent
> things, and its also necessary under windows and macos.

> >now i understood the necessity of the allocation way of
> >snd-hammerfall-mem.  we can merge the feature but it will be likely
> >after 0.9.0, as long as the old style works.  i'd like to concentrate
> >on bug fixes now.
> 
> as long as you propose to leave snd-hammerfall-mem in
> place.
> otherwise, you will make it impossible for many people to use
> their audio interfaces!

don't worry, it's been still there.  no changes regarding snd-hf-mem
without asking you :)


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: hdsp driver

[Paul Davis]

>> since snd-hammerfall-mem has nothing to do with filesystems on disk,
>> there is no danger.
>
>as long as the snd-hammerfall-mem module itself on the filesystem is 
>not broken.  it may happen not rarely if the filesystem crashed just
>after (or during) installing the new module files.

when this is done (pre-fsck), only / is mounted, and its mounted
read-only. nothing can happen.

--p


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf