snd-rme9652_mem and the H-DSP

snd-rme9652_mem and the H-DSP

[Paul Davis]

both the hammerfall and hammerfall-dsp require exactly the same kind
of memory allocation. the snd-rme9652_mem module, which allocates
a contiguous chunk of about 1.2MB of physical RAM, uses the "driver
index" to identify which snd-card is using a given buffer. this means
that if we try to use both a hammerfall and a hammerfall-dsp, things
don't work: both drivers pass "driver index" = 0 to the memory
module, and the second try (whatever it is) concludes that it already
has buffers allocated.

i propose using the card->number value instead, so that the numbers are
unique across all driver modules. 

the only other option i can see is to duplicate the code in
snd-rme9652_mem, which seems really dumb.

i also propose renaming the module to snd-hammerfall_mem to clearly
indicate its generic status, and moving it into its own directory. it
will be built if either CONFIG_SND_CARD_RME9652 and/or
CONFIG_SND_CARD_HDSP are defined.

let me know if this sounds like the right solution, or if you have a
better one.

--p




_______________________________________________________________

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

Re: snd-rme9652_mem and the H-DSP

[Jaroslav Kysela]

On Thu, 9 May 2002, Paul Davis wrote:

> both the hammerfall and hammerfall-dsp require exactly the same kind
> of memory allocation. the snd-rme9652_mem module, which allocates
> a contiguous chunk of about 1.2MB of physical RAM, uses the "driver
> index" to identify which snd-card is using a given buffer. this means
> that if we try to use both a hammerfall and a hammerfall-dsp, things
> don't work: both drivers pass "driver index" = 0 to the memory
> module, and the second try (whatever it is) concludes that it already
> has buffers allocated.
> 
> i propose using the card->number value instead, so that the numbers are
> unique across all driver modules. 
> 
> the only other option i can see is to duplicate the code in
> snd-rme9652_mem, which seems really dumb.
> 
> i also propose renaming the module to snd-hammerfall_mem to clearly
> indicate its generic status, and moving it into its own directory. it
> will be built if either CONFIG_SND_CARD_RME9652 and/or
> CONFIG_SND_CARD_HDSP are defined.
> 
> let me know if this sounds like the right solution, or if you have a
> better one.

Perhaps, we can use a more universal name like 'snd-pci-bigmem' or
something like that. Other hardware might require this (if I remember
correctly S3 SonicVibes cards also requires a big memory chunk for DLS
samples). We can move this module to /alsa-kernel/pci.

						Jaroslav

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


_______________________________________________________________

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

Re: snd-rme9652_mem and the H-DSP

[Takashi Iwai]

At Thu, 9 May 2002 16:43:32 +0200 (CEST),
Jaroslav wrote:
> 
> On Thu, 9 May 2002, Paul Davis wrote:
> 
> > both the hammerfall and hammerfall-dsp require exactly the same kind
> > of memory allocation. the snd-rme9652_mem module, which allocates
> > a contiguous chunk of about 1.2MB of physical RAM, uses the "driver
> > index" to identify which snd-card is using a given buffer. this means
> > that if we try to use both a hammerfall and a hammerfall-dsp, things
> > don't work: both drivers pass "driver index" = 0 to the memory
> > module, and the second try (whatever it is) concludes that it already
> > has buffers allocated.
> > 
> > i propose using the card->number value instead, so that the numbers are
> > unique across all driver modules. 
> > 
> > the only other option i can see is to duplicate the code in
> > snd-rme9652_mem, which seems really dumb.
> > 
> > i also propose renaming the module to snd-hammerfall_mem to clearly
> > indicate its generic status, and moving it into its own directory. it
> > will be built if either CONFIG_SND_CARD_RME9652 and/or
> > CONFIG_SND_CARD_HDSP are defined.
> > 
> > let me know if this sounds like the right solution, or if you have a
> > better one.
> 
> Perhaps, we can use a more universal name like 'snd-pci-bigmem' or
> something like that. Other hardware might require this (if I remember
> correctly S3 SonicVibes cards also requires a big memory chunk for DLS
> samples). We can move this module to /alsa-kernel/pci.

yes.  ice1712 needs relatively big chunk, too.

how about to add module options to specify the pci id and the required
size for non-default cards?


Takashi

_______________________________________________________________

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

Re: snd-rme9652_mem and the H-DSP

[Paul Davis]

>> Perhaps, we can use a more universal name like 'snd-pci-bigmem' or
>> something like that. Other hardware might require this (if I remember
>> correctly S3 SonicVibes cards also requires a big memory chunk for DLS
>> samples). We can move this module to /alsa-kernel/pci.
>
>yes.  ice1712 needs relatively big chunk, too.
>
>how about to add module options to specify the pci id and the required
>size for non-default cards?

not a bad idea. but before doing this, we should check with the
appropriate kernel lieutenant. this seems to get rather close to the whole
point of memory zones that have been in the kernel for a while now. it
might be better to pursue a more generic kernel-level solution, rather
an ALSA specific module.

who shall we ask?

--p

_______________________________________________________________

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

Re: snd-rme9652_mem and the H-DSP

[Dan Hollis]

On Mon, 13 May 2002, Paul Davis wrote:
> who shall we ask?

alan. he's been involved in this particular problem with the OSS drivers.

-Dan
-- 
[-] Omae no subete no kichi wa ore no mono da. [-]


_______________________________________________________________

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