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 eventual
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 correctly in the Ma
> > > 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
> > ...
>
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]
http:
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]
http
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 lik
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 Sou
>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 gre
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 Revoluti
>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
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
>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 th
>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 wonde
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 wro
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 vend
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:
>
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 wonder
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 Mak
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 ?
> > >
>
>> 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 ho
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 t
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
>
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
ipc_key_
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
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, di
[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 foll
At Thu, 20 Mar 2003 10:04:39 +0100 (CET),
Giuliano Pochini wrote:
>
>
> >> They are different:
> >>
> >> [aplay 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
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: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.
>> They are different:
>>
>> [aplay 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 peri
I think the documentation library used to mention the usage of dmix, but since the
last update, I can't find it anymore (normally :
http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html)
The code mentions :
This plugin provides direct mixing of multiple streams. The resolution
for 32-bi
<<< 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
alwa
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)
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 m
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 Radiodifuz
35 matches
Mail list logo
