make: Nothing to be done for `all-deps'.
autoconf: Undefined macros:
configure.in:797: AC_DEFINE_CONFIG_SND_SEQ_DUMMY)
Should read : AC_DEFINE(CONFIG_SND_SEQ_DUMMY)
--
ing. Andrei Boros
mailto:[EMAIL PROTECTED] / +40-21-303-1870
Centrul pt. Tehnologia Informatiei
Societatea Romana de
I got make 3.79 installed, hopefully the sequencer module problems will
be solved, but I get a tiny error that didn't appear before when runing
cvscompile :
I updated the cvs tree, did a make clean, deleted Makefile, then ran
./cvscompile.
This is the first line it outputs:
make: *** No rule to
On Thu, 20 Mar 2003, Andrei Boros wrote:
make: Nothing to be done for `all-deps'.
autoconf: Undefined macros:
configure.in:797: AC_DEFINE_CONFIG_SND_SEQ_DUMMY)
Should read : AC_DEFINE(CONFIG_SND_SEQ_DUMMY)
I have this line in my tree:
AC_DEFINE(CONFIG_SND_SEQ_DUMMY_MODULE)
Makefile.conf.in
CONFIG_SND_SEQ_DUMMY= @CONFIG_SND_SEQ_DUMMY@
===
CONFIG_SND_SEQ_DUMMY= @CONFIG_SND_SEQUENCER@
1.52
I got again this inconsistency in Makefile.conf.in when updateing the
cvs tree.
I am wandering, this looks to me that snd-seq-dummy.o will be built
always if
They are different:
[aplay no options track.wav]
Mar 19 19:21:23 localhost kernel: pcm_hw_params (bufsize=88200 periods=3
persize=22052)
bufsize==88200 != 3*22052 == 66156
Note that there is no guarantee that the periods == integer value.
If your hardware doesn't allow to set
At Thu, 20 Mar 2003 10:28:57 +0200,
Andrei Boros wrote:
Makefile.conf.in
CONFIG_SND_SEQ_DUMMY= @CONFIG_SND_SEQ_DUMMY@
===
CONFIG_SND_SEQ_DUMMY= @CONFIG_SND_SEQUENCER@
1.52
I got again this inconsistency in Makefile.conf.in when updateing the
cvs tree.
I am wandering,
At Thu, 20 Mar 2003 10:20:53 +0200,
Andrei Boros wrote:
I got make 3.79 installed, hopefully the sequencer module problems will
be solved, but I get a tiny error that didn't appear before when runing
cvscompile :
I updated the cvs tree, did a make clean, deleted Makefile, then ran
At Thu, 20 Mar 2003 10:04:39 +0100 (CET),
Giuliano Pochini wrote:
They are different:
[aplay no options track.wav]
Mar 19 19:21:23 localhost kernel: pcm_hw_params (bufsize=88200 periods=3
persize=22052)
bufsize==88200 != 3*22052 == 66156
Note that there is no guarantee that
[i sent this mail already yesterday, but it seems not reached by
unknown reason. if you have already seen this, please disregard.]
At Wed, 19 Mar 2003 14:11:08 +0100,
Pieter Palmers wrote:
Hi,
I'm currently writing a driver for the Guillemot MaxiStudio ISIS card,
and I have the
At Thu, 20 Mar 2003 12:49:26 +0200,
Andrei Boros wrote:
Takashi Iwai wrote:
I got make 3.79 installed, hopefully the sequencer module problems will
be solved, but I get a tiny error that didn't appear before when runing
cvscompile :
I updated the cvs tree, did a make clean,
At Wed, 19 Mar 2003 09:20:28 -0800,
Stephen Hassard wrote:
Hi there,
I'm trying to update the version of Alsa in the Linux kernel v2.5.65 from CVS.
Their doesn't seem to be any documentation on how to do this the *right* way.
It seems that what one should do is copy the CVS/alsa-kernel
At Thu, 20 Mar 2003 10:02:06 +0100,
Kristof Pelckmans wrote:
I wonder how you know that the number you assign is not in use...
well, there is no guarantee for that.
i think it would be more understandable to have the string type ipc
key, such as
pcm.dmix {
type dmix
On Thu, 20 Mar 2003, Takashi Iwai wrote:
At Thu, 20 Mar 2003 10:02:06 +0100,
Kristof Pelckmans wrote:
I wonder how you know that the number you assign is not in use...
well, there is no guarantee for that.
i think it would be more understandable to have the string type ipc
key, such
On Thu, 20 Mar 2003, Giuliano Pochini wrote:
Ok, but how do I build the sg list when bufsize!=sz*periods ? Take
the example above: have I to build 4 periods and let the last one
smaller than 22052 ?
it depends on the hardware.
There are no hw constraints IFAIK, but the hw does not
Ok, but how do I build the sg list when bufsize!=sz*periods ? Take
the example above: have I to build 4 periods and let the last one
smaller than 22052 ?
it depends on the hardware.
There are no hw constraints IFAIK, but the hw does not provide the
current dma address. It tells me how many
At Thu, 20 Mar 2003 15:24:20 +0100 (CET),
Jaroslav wrote:
On Thu, 20 Mar 2003, Giuliano Pochini wrote:
Ok, but how do I build the sg list when bufsize!=sz*periods ? Take
the example above: have I to build 4 periods and let the last one
smaller than 22052 ?
it depends on the
The following configure scripts generates makefiles that disregards
`--with-alsa-inc-prefix=/path/to/includes':
alsa-tools-0.9.0rc7/ac3dec/configure
alsa-tools-0.9.0rc7/sb16_csp/configure
alsa-tools-0.9.0rc7/seq/sbiload/configure
The variable `ALSA_CFLAGS' gets set corectly in the
Hi,
I have a EgoSys / ESI Waveterminal 192M card using an Envy24HT chip (aka
VIA VT1724 i think), which is possible to support according to the
matrix, but no driver has been written yet.
Ive seen a few threads in the archive which suggest people were looking
at development, and i was just
Excuse my ignorance, but do you mean vendor specific details or chipset
details ?
There is a patch for the Envy24HT here, which i just found in the
archives if its any use.
http://www.mail-archive.com/[EMAIL PROTECTED]/msg05500.html
chris
On Thu, 2003-03-20 at 17:49, Daniel Pouzzner wrote:
Unfortunately, the firmware in the Waveterminal 192's has a different
version number (version 220 or somesuch) than that addressed by those
patches (version 1), and the firmware is sufficiently different that
Waveterminals don't work. You can do amixer stuff, but no actual
sound. So it's the
So theres no hope unless the vendor will release some data ?
If its any use, theres a thread here of from linux-audio-dev, by a guy
who got some code out of EgoSys no code for the waveterminal though.
http://eca.cx/lad/2002/06/0167.html
chris
On Thu, 2003-03-20 at 18:12, Daniel Pouzzner
I have a EgoSys / ESI Waveterminal 192M card using an Envy24HT chip (aka
VIA VT1724 i think), which is possible to support according to the
matrix, but no driver has been written yet.
Ive seen a few threads in the archive which suggest people were looking
at development, and i was just wondering
So theres no hope unless the vendor will release some data ?
I don't know, but my assumption is that the 192's are coded green in
the matrix because ESI disclosed the required details without NDA
strings attached. We just need to find out if this is actually the
case, and if so, where to get
Is there an authoritative person on vendor data ? i'd imagine that
whoever maintains the matrix must have had it on good authority, that
data had been released.
chris
On Thu, 2003-03-20 at 18:26, Daniel Pouzzner wrote:
So theres no hope unless the vendor will release some data ?
I don't
Is there an authoritative person on vendor data ?
One would think so, at least de facto - whoever maintains the matrix.
I emailed [EMAIL PROTECTED] about the issue but got no response.
---
This SF.net email is sponsored by: Tablet PC.
Does
On Thu, 20 Mar 2003, Daniel Pouzzner wrote:
Is there an authoritative person on vendor data ?
One would think so, at least de facto - whoever maintains the matrix.
I emailed [EMAIL PROTECTED] about the issue but got no response.
Evny24HT chip is supported in our CVS (MidiMan Revolution
It is not usually difficult to do the reverse engineering
and collect a schematic how is the envy chip connected with the I/O chips
using a simple voltmeter.
Umm, I think you underestimate the skills you have amassed that make
such an operation seem easy to you!
I think that the card is green
I have just installed Red Hat Linux 7.3 on my pc at
work and will be installing the ALSA drivers. However, the sound card is
described as a "SoundMax integrated Audio" (I don't really know much about this
card and cannot find it on the ALSA soundcard matrix). I have read
that it is a
just to clarify: all 3 plugins will not enable several processes to use the same
soundcard's channels, i.e. software mixing?
Thanks,
Florian
Hi all,
the dmix plugin was extended to support channel bindings and
mixing code for 32-bit samples (24-bit resolution).
I'd like to
On Thu, Mar 20, 2003 at 02:13:18PM -0800, Florian Bomers wrote:
just to clarify: all 3 plugins will not enable several processes to use the same
soundcard's channels, i.e. software mixing?
dmix does just that. Works fine here, ipc_key stuff and all :)
--
Ville Syrjälä
[EMAIL PROTECTED]
On Thu, Mar 20, 2003 at 02:13:18PM -0800, Florian Bomers wrote:
just to clarify: all 3 plugins will not enable several processes to use the same
soundcard's channels, i.e. software mixing?
dmix does just that. Works fine here. ipc_key stuff and all :)
--
Ville Syrjälä
[EMAIL PROTECTED]
I wonder how you know that the number you assign is not in use...
well, there is no guarantee for that.
i think it would be more understandable to have the string type ipc
key, such as
pcm.dmix {
type dmix
ipc_key_str /usr/alsa/foo
...
}
which generates
Fernando Pablo Lopez-Lezcano wrote:
It would be nice that the user not need to type magic numbers into a
configuration file, unique or not. I don't know what it involves, but it
would make using the configuration file much easier.
Even nicer is if this could be embedded like the dmix was
33 matches
Mail list logo
