I'm trying to build Takashi's version of latencytest (0.5.3) and
apparently something has changed in the kernel (or I have something that
I need to turn on in the config options?). This is what I get:
# make -f Makefile.module
make -C /lib/modules/`uname -r`/build SUBDIRS=`pwd` modules
make[1]:
$ measure -p ./out/x11.png -o ./out/x11.out -c 0 -f 1024 -n 2 -t 2
I get this error message: error setting freq 1024
probably a permissions problem. try it as root.
This is while runng at root. (Sorry for the $ I typed that one by
hand).
A tip from Tim Goetze to do:
# echo
I confirm this fact:
with kernel 2.4.23 and alsa 1.0rc2, the module snd-rme9652 can't be loaded
althought the old rme digi 9652 is perfectly working with alsa 0.9.6
I have found after a lot of printk that if I comment lines 1645 to 1648
of rme9652.c, the driver could be load and I can
On Sun, 2003-12-14 at 06:48, Chris Cannam wrote:
On Sunday 14 Dec 2003 2:34 pm, Chris Cannam wrote:
On Sunday 14 Dec 2003 2:02 pm, Jan Depner wrote:
If I'm not mistaken the timing for your audio is coming from your
sound card not your system clock.
[...]
I mentally ruled out a
At Mon, 24 Nov 2003 14:59:42 +,
Thierry Vignaud wrote:
[1 text/plain (7bit)]
Fernando Pablo Lopez-Lezcano [EMAIL PROTECTED] writes:
I think we need a similar extension to support Mandrake, after
installation from the sources all modules in modules.conf where
gone
I think we need a similar extension to support Mandrake,
after installation from the sources all modules in
modules.conf where gone, except the ones from alsa.. :-)
I think the patch will fix mandrake too. I have the dubious
honor of being able to claim ownership
I think we need a similar extension to support Mandrake, after
installation from the sources all modules in modules.conf where gone,
except the ones from alsa.. :-)
I think the patch will fix mandrake too. I have the dubious honor of
being able to claim ownership of the original bug :-(
Included is a patch that fixes alsaconf to work correctly under fedora
core 1. Otherwise alsaconf happily creates a modules.conf file that only
contains the alsa configuration and nothing else (a path in the if's
that does not create a $TMP file before the alsa configuration process
starts).
This is not a new problem on my system, but I wanted to get up to
date with Alsa before I presented it here. If I do a cold boot then Alsa
is correctly installed and both my HDSP 9652 and my MidiSport 2x2 are
detected and work fine. However, after a warm boot Alsa never installs
for the
I'm trying to build RPMs from alsa-driver-0.9.7 (on Mandrake 9), and at
the end of the process, rpm reports 'installed but unpackaged' files:
Checking for unpackaged file(s): /usr/lib/rpm/check-files
/var/tmp/alsa-driver-0.9.7-root
error: Installed (but unpackaged) file(s) found:
OK, compiled, installed etc. But no lockups with a 2.4.20 kernel. Is
there anything in particular that triggers it?
i don't know. i just know that both my system and that of my first
paying customer lock up when JACK is run SCHED_FIFO, and it
normally happens within 10 minutes.
There was a
I have noticed a change in the behavior of the snd-seq module. It no
longer seems to be loaded automatically (this started to happen around
0.9.1 or so). I had to change the alsasound script to load it explicitly
for things to work as before.
If I do not do that a program that needs it (for
Hi gurus... I'm having problems getting sound out of this laptop:
NEC LM800J/7
I'm using 2.4.20-pre6 + current alsa cvs (post 0.9.2)... After
installing everything is fine, drivers load perfectly, I unmute all
controls, raise all volumes and aplay seems happy playing a soundfile,
Hi gurus... I'm having problems getting sound out of this laptop:
NEC LM800J/7
I'm using 2.4.20-pre6 + current alsa cvs (post 0.9.2)... After
installing everything is fine, drivers load perfectly, I unmute all
controls, raise all volumes and aplay seems happy playing a soundfile,
except I get no
Hi gurus... I'm having problems getting sound out of this laptop:
NEC LM800J/7
I'm using 2.4.20-pre6 + current alsa cvs (post 0.9.2)... After
installing everything is fine, drivers load perfectly, I unmute all
controls, raise all volumes and aplay seems happy playing a soundfile,
except I
Is there a way to know if a kernel module (loaded or not) is an alsa or
oss module? I know about modinfo but the information it provides does
not allow you to find out which api the module supports. In fact, is
there a way to know if a module is a _sound_ driver?? (I would like to
be able to list
Is there a way to know if a kernel module (loaded or not) is an alsa or
oss module? I know about modinfo but the information it provides does
not allow you to find out which api the module supports. In fact, is
there a way to know if a module is a _sound_ driver?? (I would like to
be able to
I have upgraded the envy24control program to use gtk2.
To make the layout work I have changed it from fixed to hbox/vbox, but I
have tried not to change the structure og the gui-file envy24control.c.
It will also work with gtk1.
Hi gurus, I'm seeing this weird problem in current cvs (same problem
when tested with cvs of 20030307):
Connections:
Oxygen8 Midi output - Quattro Midi input
Quattro USB - laptop USB port
- start computer (with everything connected)
a) usb system is loaded..., Quattro recognized,
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
Sure. First example is for the dmix plugin and ice1712 (10 playback
channels - last two are S/PDIF, so this configuration allows sharing of
the S/PDIF jack):
pcm.dmix_spdif {
type dmix
ipc_key 5678293
Hmm, sorry for my ignorance, but what does this number mean and where
is anybody else using gcc 3.2.2 to compile their kernel and ALSA CVS?
I'm currently using gcc-3.2 (default redhat compiler for 8.0- not 3.2.2,
I know) for a preliminary planet ccrma kernel. I'm currently running it
in my laptop and a couple other computers. I did not have any problems
so far
Thanks! I started working on differentiating in the alsasound alsa
startup script between a full start (all modules are loaded when
alsasound executes) and a partial start (some of the modules are already
loaded when alsasound executes and it has to load the rest).
The first naive
alsasound script calls alsactl and card-specific scripts (if any).
this should be avoided in the case of partial load.
Yes, I took care of executing them just for the cards that had been
loaded.
IIRC, modprobe returns 0 even if called with the existing module.
(if the load failed,
lists about this and to do it cleanly it would be nice to have available
in /proc/asound the list of modules currently loaded. That is not
available today (I think Takashi said he might add that).
cat /proc/modules | grep '^snd'
This relies in an (AFAIK) unenforceable
lists about this and to do it cleanly it would be nice to have available
in /proc/asound the list of modules currently loaded. That is not
available today (I think Takashi said he might add that).
cat /proc/modules | grep '^snd'
I wrote this:
This relies in an (AFAIK) unenforceable
Note that the problem is already solveable with a nice way. The SuSE uses
this hotplug script:
-
#!/bin/bash
#
# /etc/hotplug/usb/alsasound
#
# Sets up newly plugged in USB audio/MIDI devices.
#
if [ $INTERFACE != ]; then
IFS=/
set $INTERFACE ''
lists about this and to do it cleanly it would be nice to have available
in /proc/asound the list of modules currently loaded. That is not
available today (I think Takashi said he might add that).
cat /proc/modules | grep '^snd'
This relies in an (AFAIK) unenforceable convention (all
I was just wondering how can I force snd-usb-midi to assume device 2
slot, rather than the default 0 when spawning, since at boot time on my
machine USB gets initialized before alsa and therefore if I have
Midisport 2x2 hooked up, it ends up being my default /dev/dsp device
(which actually
I _think_ this is the fix, please check (the error is undeclared
variable ctl)...
--- alsa-kernel/core/timer.c~ 2003-02-06 11:21:11.0 -0800
+++ alsa-kernel/core/timer.c2003-02-06 15:19:26.0 -0800
@@ -953,7 +953,7 @@
}
spin_unlock(tu-qlock);
if (_wake)
1) Old problem - if my MidiSport 2x2 is plugged in when I cold boot,
then Alsa gets loaded when the MidiSport is found. When I get to the
part of the boot process where Alsa is supposed to get started, I get a
'Failed' message, telling me Alsa is already running. Even this is OK,
but then
It would be useful to have an option to force the alsa-driver configure
script to use a target architecture for the build different from the
architecture of the running kernel (ie: I'm running a i386 kernel but
want to build for the same kernel, but with the i686 architecture).
Or is there a way
Very strange:
I'm seeing this while trying to compile the alsa drivers:
gcc -D__KERNEL__ -DMODULE=1
-I/usr/src/redhat/BUILD/alsa-driver-0.9.0/include
-I/lib/modules/2.4.19-1.llsmp/build/include -O2
-mpreferred-stack-boundary=2 -march=i686 -D__SMP__ -DCONFIG_SMP -DLINUX
-Wall
[I sent this to linux-audio-devel by mistake... no clue what I was
thinking]
Date: 17 Jan 2003 18:01:14 -0800
Very strange:
I'm seeing this while trying to compile the alsa drivers:
gcc -D__KERNEL__ -DMODULE=1
-I/usr/src/redhat/BUILD/alsa-driver-0.9.0/include
On Tue, 2002-12-17 at 03:06, Takashi Iwai wrote:
At 16 Dec 2002 19:46:55 -0800,
Mark Knecht wrote:
On Mon, 2002-12-16 at 18:51, Paul Davis wrote:
i think it would something like this:
options snd-hdsp snd_index=0
options snd-usb-foo snd_index=1
i'm sure that takashi or
I also noticed that the adc controls have a weird behavior (in a
delta66). I start both alsamixer and envy24control. I can control the
adc volume for each channel from both of them. I can quit and restart
alsamixer and everything is fine. If I quit and restart envy24control
all
Freshly compiled 0.6.0pre3 on RedHat 8.0. Using current (fresh compile)
alsa CVS and a Midisport 2x2 usb midi interface. This is what happens
(finally found some sequence of events I could repeat!):
- erase previous muse configuration files to start from scratch
- unplug midi interface
- stop
This fixes sequencer input from USB MIDI. Both usbmidi.c and seq_midi.c
thought they could use substream-runtime-private_data for themselves.
Thanks! sequencer input is now working on Muse (both 0.5 and 0.6
versions)! Regretfully output seems to not work now :-(
If I turn on debugging in Muse
This fixes sequencer input from USB MIDI. Both usbmidi.c and seq_midi.c
thought they could use substream-runtime-private_data for themselves.
Thanks! sequencer input is now working on Muse (both 0.5 and 0.6
versions)! Regretfully output seems to not work now :-(
If I turn on debugging
OSS emulation (raw midi interface):
Midi input and output works fine on the first port,
ALSA:
input does not seem to work at all.
Werner Schweer wrote:
same on my Roland/Edirol UA100 (audio + 2 midi ports).
Martin Langer wrote:
last but not least: same on my Evolution MK-249C
ALSA:
cat /proc/asound/devices shows only one raw midi interface. This is on
a two port device (but Muse lets me select either port). On the older
alsa two devices show up on the listing.
For multiport interfaces, the additional ports are available as subdevices
of the
ALSA:
cat /proc/asound/devices shows only one raw midi interface. This is on
a two port device (but Muse lets me select either port). On the older
alsa two devices show up on the listing.
For multiport interfaces, the additional ports are available as subdevices
of
[sorry for the wide distribution]
Is anyone out there trying out this combination?:
kernel 2.4.20-rc1
capabilities patch
low latency patch
preemptible kernel patch
almost current alsa cvs [20021028.170432 usa pacific time]
If I start jackd and then use the freqtweak jack client I get a
Current cvs, just compiled, the sound driver seems to start fine but I get
no sound. Alsamixer cannot move the volume in the DAC sliders up from 0
(it gets to at most 2). Same in envy24control. Envy24control reports the
following when started:
envy24control
Unable to write volume change rate:
Note: If
SND_COMPATIBILITY_BUILD_RC3 is defined,
then applications need to fall back to 0.9.0rc3 API
as well.
So maybe we could have a --with-compat-rc3 option for
alsa-utils as well? Regardless of which alsa-lib I
build, I always need to be able to build alsa-utils.
And I
I'm using 2.4.20-pre4 + lowlat + preempt + capabilities + acpi
(I think that's all)
anyway, i changed the relevant part on cvs. please try once to
update.
I'll try again...
Compiles fine and seems to be working ok (intel8x0). I don't
know what the situation was
I just tried cvs and I'm getting an unresolved symbol error
on snd.o, pci_alloc_consistent
this is likely because of my last change.
which kernel are you using?
perhaps pci_alloc_consistent() is defined as a macro for some other
function in your kernel.
I'm using 2.4.20-pre4 +
I just tried cvs and I'm getting an unresolved symbol error
on snd.o, pci_alloc_consistent
this is likely because of my last change.
which kernel are you using?
perhaps pci_alloc_consistent() is defined as a macro for some other
function in your kernel.
I'm using 2.4.20-pre4 + lowlat +
[sent also to alsa-dev - maybe I missed an announcement about this?]
The jack (Jack Audio Connection Kit, cvs from around the beginning of
September) code no longer compiles with the most recent alsa cvs:
There has been a backwards incompatible alsa api change. This is recent, I
If the API change is desirable and _has_ to be made there
should be an announcement (to alsa-dev which is where I assume
is where all developers of alsa applications are subscribed
to), and the library version should be increased so that an
application compiled with the old version will not
Correct me if I'm wrong but bumping the library version number
from .so.2 to .so.3 with api changes would also enable orderly
migration _if_ the interface between the library and the
drivers does not change. I would be able to have both a .so.2
and a .so.3 in the system, so that old,
The updated code in CVS should be more verbose. Could you try it and send
me related lines from /var/log/messages? Thanks.
Here's the error message from the cvs version, it appears to add a little
bit more information to what I sent before:
Sep 9 20:25:57 pc1 kernel: PCI:
[sent also to alsa-dev - maybe I missed an announcement about this?]
The jack (Jack Audio Connection Kit, cvs from around the beginning of
September) code no longer compiles with the most recent alsa cvs:
alsa_driver.c: In function `alsa_driver_set_parameters':
alsa_driver.c:403: too few
# alsamixer
alsamixer: simple.c:869: simple_add1: Assertion
`!simple-ctls[type].elem' failed.
Aborted
could you try to remove the assert() at alsa-lib/src/mixer/simple.c
line 869? this looks like a wrong conditional...
It's ok. Could you
Sure, it is included at the end of the email. I found the
same problem yesterday in an ens1371 based soundcard.
I've fixed the problem in CVS for intel8x0
Something else has changed, I now get a:
could you check where the error is returned (e.g. by primitive printk's)
? i
I'll try, I don't know exactly where it could be failing but I'll try to
find out (I'll have to read a lot of code :-) The error is not
instantaneous, it takes almost a second (maybe) to fail, there must be a
timeout somewhere.
The updated code in CVS should be more verbose. Could
I'll try, I don't know exactly where it could be failing but I'll try to
find out (I'll have to read a lot of code :-) The error is not
instantaneous, it takes almost a second (maybe) to fail, there must be a
timeout somewhere.
The updated code in CVS should be more verbose. Could
# alsamixer
alsamixer: simple.c:869: simple_add1: Assertion
`!simple-ctls[type].elem' failed.
Aborted
could you try to remove the assert() at alsa-lib/src/mixer/simple.c
line 869? this looks like a wrong conditional...
It's ok. Could you send us output from
Fernando Pablo Lopez-Lezcano wrote:
After installing a new cvs version I'm getting an assertion failure in
alsamixer (or amix).
# alsamixer
alsamixer: simple.c:869: simple_add1: Assertion
`!simple-ctls[type].elem' failed.
Aborted
could you try to remove the assert
After installing a new cvs version I'm getting an assertion failure in
alsamixer (or amix).
# alsamixer
alsamixer: simple.c:869: simple_add1: Assertion `!simple-ctls[type].elem'
failed.
Aborted
could you try to remove the assert() at alsa-lib/src/mixer/simple.c
line 869? this
Found in current cvs:
# depmod -ae
depmod: *** Unresolved symbols in
/lib/modules/2.4.18-10.llsmp/kernel/drivers/sound/isa/snd-dt0197h.o
depmod: snd_sbdsp_create_Rsmp_3f86b411
depmod: snd_sbmixer_new_Rsmp_2880de09
depmod: snd_sb16dsp_pcm_Rsmp_4d33d580
-- Fernando
However, I still feel that my original gripe (the error message
output) is valid. In all other cases that I'm aware of, you never
automatically spit out an error message to stderr or stdout. Why
should it be different in this case? There is an error retrieval
mechanism in place,
I get this in alsa-utils
/usr/local/src/music/alsa/alsa-utils# ./cvscompile
--with-cards=intel8x0,cmipci,usb-audio,usb-midi
--with-sequencer=yes;make;make install
aclocal: configure.in: 11: macro `AM_PATH_ALSA' not found in library
/usr//share/automake/am/depend2.am: AMDEP does
Hi, we're starting to test a new hdsp Hammerfall card (thanks
Paul!!) and we're running into some small problems (jack works
great, as would be expected). This is for a freshly compiled
alsa cvs download as of this morning, running under
2.4.19-pre8 + ll + preempt, Hammerfall DSP pci card +
Hi, today's cvs, fresh download. Not all modules are compiled
when doing a cvscompile from scratch. Last ones are the usb
modules, the whole pci directory is apparently skipped. The
final depmod also fails (maybe because there are modules
missing?):
/sbin/depmod -a -e -b
as fernando reported:
depmod: *** Unresolved symbols in
/lib/modules/2.4.19-pre6/kernel/sound/pci/rme9652/snd-hammerfall-mem.o
depmod: pci_free_consistent
depmod: pci_alloc_consistent
depmod: pci_devices
depmod: mem_map
depmod: printk
depmod: ***
Just downloaded from cvs, I'm getting this unresolved symbols:
# depmod -a -e
depmod: *** Unresolved symbols in
/lib/modules/2.4.18-2.ll/kernel/drivers/sound/pci/rme9652/snd-hammerfall-mem.o
depmod: pci_free_consistent
depmod: pci_alloc_consistent
depmod: pci_devices
Actually, I think I found the problem. I was using the maximum number
of playback and captures channels reported by the device. For
plughw, this number is apparently 1, rather than the actual
number the hardware supports! I guess what I have to do is open the
hw device first to get
On Sun, 24 Mar 2002, Ken McMillan wrote:
Actually, I think I found the problem. I was using the maximum number
of playback and captures channels reported by the device. For
plughw, this number is apparently 1, rather than the actual
number the hardware supports! I guess what I have to do
Actually, I think I found the problem. I was using the maximum number
of playback and captures channels reported by the device. For
plughw, this number is apparently 1, rather than the actual
number the hardware supports! I guess what I have to do is open the
hw device first to
70 matches
Mail list logo
