From alsa-devel-owner@alsa.jcu.cz  Wed Apr 22 12:17:14 1998
Received: from entry.jcu.cz (perex@entry.jcu.cz [160.217.1.111])
	by marvin.jcu.cz (8.8.8/8.8.8) with SMTP id MAA13937;
	Wed, 22 Apr 1998 12:16:49 +0200
Date: Wed, 22 Apr 1998 12:16:49 +0200 (MET DST)
From: Jaroslav Kysela <perex@jcu.cz>
To: LGB of DC <lgb@hal2000.hal.vein.hu>
cc: alsa-devel@alsa.jcu.cz
Subject: Re: alsa questions + ideas [long ...]
In-Reply-To: <19980422094522.11791@hal2000.hal.vein.hu>
Message-ID: <Pine.LNX.3.96.980422100042.6809A-100000@entry.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

On Wed, 22 Apr 1998, LGB of DC wrote:

> Hello !
> 

[cutted..]

> PROBABLY this is the problem (mute ...). But how can I disable muting ?

[cutted..]

> Can you help me ?
> 
> I see the system V rc init script, but I don't like to be constant
> modules in my low-memory-computer :) kerneld is great I like it :)

OK. This is general problem for Linux kernel (it's not specific to sound
driver). There is currently no way, how can be store runtime module
setting if kernel removes autoclean module. We have big discussion about
this in your alsa-devel mailing list and I don't know to this time about
reasonable method...

> I've just seen in gusmax.c the code which initializes the mixer setting
> code, but it's beetween "#if 0 ... #endif" ...

This code isn't needed. If you want set some initial volume settings for
mixer use 'post-install gus-max cat /etc/mixer > /proc/sound/0/mixer0'
line in your /etc/conf.modules (example is for GUS MAX soundcard). This
doesn't solve situation:

1. Some program which uses digital audio is executed...
2. post-install setups some default volume
3. Volume is very loud - you change mixer settings...
4. Program stops and ALSA driver isn't used for long time - kernel removes it.
5. Same program which uses digital audio is executed...
6. post-install setups some default volume (there is currently no way how
   to store previous settings)...
7. You _MUST_ change mixer settings again manually - this is bad...

Maybe idea with one resident module (which will be in kernel forever)
which will export functions like 'snd_get_value' and 'snd_put_value' will
be reasonable. There should be problem with ISA DMA allocation, too. So
this module should allocate requested number and size of DMA buffers at
boot when memory is free.

> - - - - - - - - - -
> 
> Some simple questions :
> 
> Can I use only one DMA ? I tried. "Unable to ..." ...

It should work (I didn't test it very much) with 'snd_dma2=-1' option for
module which disables second DMA channel...

> As far as I know ESS card is supported only in 8 bit mode by OSS/Lite.
> Can alsa use it in 16 bit mode ?

ALSA and OSS/Lite can play/record with ESS card 16-bit samples or what you
mean? ESS card uses only one 8-bit DMA channel.

> I want to install nas (network audio server). With both of OSS/Lite &
> ultrasound project driver I can't do it (after server starting,
> there is an error), but with alsa it works :) strange ...
> Unfortunetly it's very bad (seconds of pauses during playing), and
> after some minutes, alsa refusing to play any sound in any way ...
> What can be the problem ?

I don't know.. Can you give me pointer to NAS?

> - - - - - - - - - -
> 
> I've got only 16 megabytes of ram at the moment, and - you know - running
> X, applications ... etc at the same time gives lots of work for the system.
> Because of this eg an mp3 playing sometimes casued to stop sound for a
> short time. I see that OSS does its work quite well : the stopping is very rare.
> When I started to work with the ultrasound project (2.72a), I discovered
> that it's MUCH more featured but it's MUCH MORE affected with this problem.
> Alsa - imho - the best it plays under massive disk I/Os and on high load
> too without stopping and stopping. (for GUSes is it based
> on the ultrasound project drivers ?)

I can't help you with underruns problem. You can check actual status of
PCM underruns and buffer status with cat of /proc/sound/0/pcm0 interface.
I don't like for example x11amp which setups only 4 * 4kB PCM buffer which
isn't very good for 16-bit 44.1Khz stereo playback. This causes underruns
for my dual Pentium Pro 150Mhz / 64MB RAM, too. ALSA have code for PCM a
little bit another from ultra project, but it comes from ultra project.

> - - - - - - - - - - 
> 
> Another question : /dev/sequencer seems not to be supported.
> How can I play mid,xm etc files with using the wavetable feature of
> my GUS card ? It would be very important. (THE sound card - I think -
> can produce sound transfered directly from the computer in real time,
> and on-board mixing from its own memory [wave-table])
> So USS compatible sequencer is essential, I think. Or is there any
> alternative for this job in alsa ?

You must wait for this feature. I started this project before three months
and I can't do all things at same time... It's planned...

> In my last letter I talked about a DirectSound-like API. I think it
> would be fine, if there would be some wavetable-related /dev/ entries
> which hide the differencee between various wavetable cards. So it would
> be a virtual wavetable card which would be the SAME from the view point
> of an alsa application.

Yep.. I agree..

> Since I'm really interested in sound-card programming (but I've coded
> under DOS & asm before) I would help alsa developmenting, idea-cooking,
> testing etc, but unfortunetly my studies don't allow me to have got
> much free time :(

All activities are good...

> How can I learn more about the alsa concept ? It's very good that alsa
> is a multi module layered architecture so a module is for the sound
> driver in gerneral, a module for the chipset etc. I hope that the "interface"
> of these modules will be standard. I think idea of free softwares, the
> FSF, GPL feeling are great, but ... the computer market unfortunetly aren't
> based on the freedom. So it would be nice to create a STANDARD allowing
> hardware developers to create binary drivers for their product under Linux
> too. What do you think about it ? (and it's not only for alsa ...
> it would be nice EVERYWHERE ... Linux is great (I'm using only Linux)
> but non-programmers can't (and don't want to) compile kernels, drivers,
> etc ...)

I'm saying NO... This is currently impossible do cross-kernel version
binary kernel modules... If some company want make driver without sources,
it can use staying interface (header files for user space) and make all
code in own way... If we make some proposal of internal interface then we
can't make some changes in this interface in future... This cause stop of
evolution of driver and gives down power of Linux. If you look to 2.0
kernel and 2.1 kernel there are in internal interfaces are very big
changes (for example select isn't present in 2.1, new is poll).

To binary distributions: It depends on distribution creators which kernel
modules add to your distribution.

> And I've got a problem with kernel modules : a module allocates pages (4K
> on intel), is it right ? If it's true, there is much memory since
> sub-pages/bytes cannot be allocated and there will be MANY kernel modules
> for a sound card ... is it right ? The second : can an alsa module

Yes, but unused bytes aren't very important. In very bad case module waste
only 4093 bytes of memory.

> support more than one card ? For example, I've got a gus max and a gus
> classic, so snd_gus module is only needed in one copy in the memory, isn't it ?

Each end-level ALSA modules can support more cards of same type (for
exaple GUS Classic). ALSA tries maximaly share code, so if you have GUS
MAX and GUS Classic only end-level modules differs and all other modules
are shared.

> Oh, by the way, what do you want to do with the ultrasound project ?
> Do you think that alsa will contain the features of ultrasound project
> in its gus module ? Or how ?

I'm planning move all features from ultra project to ALSA project.

> Is it planned to support SB awe cards too ?

SB AWE cards are supported in ALSA, but I should say that I probably
willn't work on WaveTable code for EMU-8000 chips...

							Jaroslav

-----
Jaroslav Kysela <perex@jcu.cz>
Academic Computer Centre, University of South Bohemia
Branisovska 31, C. Budejovice, CZ-370 05 Czech Republic



