lsmod should give you something like this: Module Size Used by es1371 30128 0 ac97_codec 8736 0 [es1371] rme96xx 13136 0 sound 63136 0 (unused) soundcore 4592 8 [es1371 rme96xx sound]
So far so good - I managed to get "soundcore" and "rme96xx" loaded.
./configure --enable-rme
Also fine.
start pd *without* option -rme, e.g.
The documentation says that "-rme" is to use Ritch's 9652 driver. Isn't this what we're doing?
pd -inchannels 8 -outchannels 8
Doesn't work. It launches, sometimes gives me
OSS: requested audio buffer size 14112 limited to 4096
(are we supposed to be using OSS at all?) and then just says
Pd: system call timed out
at which stage it's essentially dead; the GUI thread is running but nonfunctional.
Specifying "-verbose" suggests that this is coming from OSS.
So I try "pd -verbose -rme" and get as far as "RME open" before it just fails in the way I described (failing to find the entries in /dev).
Aside: comment from Andreas Poegl (I think: the PD list archive is out of date so I can't see the details) about the path settings for rme96xx: nope. The Makefile is broken since (in Red Hat 7.1) the first line of version.h is now a #include, not a definition of UTS_RELEASE.
Oh, and the xrmectrl program still appears nonfunctional.
Anyone got any ideas what I'm doing wrong? At this stage I'm thinking of completely giving up on PD as a viable option for this project.
HI Nick,
Well, "pd -rme" and "./configure --enable-rme" are both to use Ritch's driver. But "rme96xx" Is Guenter Geiger's newer, OSS driver for RME. Therefore you don't have to flag ./configure and the correct invocation is indeed "pd -inchannels 8 -outchannels 8"..
I'm grasping at straws here, but are you sure the es1371 module was loaded _after_ the rme96xx one? Otherwise Pd is trying to open your es1371. Perhaps there's some reason it can't do 8 channels that way.
Even if not, what does just "pd" do?
bon courage, Miller
./configure --enable-rme
Also fine.
start pd *without* option -rme, e.g.
The documentation says that "-rme" is to use Ritch's 9652 driver. Isn't this what we're doing?
pd -inchannels 8 -outchannels 8
Doesn't work. It launches, sometimes gives me
OSS: requested audio buffer size 14112 limited to 4096
(are we supposed to be using OSS at all?) and then just says
Pd: system call timed out
at which stage it's essentially dead; the GUI thread is running but nonfunctional.
Specifying "-verbose" suggests that this is coming from OSS.
So I try "pd -verbose -rme" and get as far as "RME open" before it just fails in the way I described (failing to find the entries in /dev).
Aside: comment from Andreas Poegl (I think: the PD list archive is out of date so I can't see the details) about the path settings for rme96xx: nope. The Makefile is broken since (in Red Hat 7.1) the first line of version.h is now a #include, not a definition of UTS_RELEASE.
Oh, and the xrmectrl program still appears nonfunctional.
Anyone got any ideas what I'm doing wrong? At this stage I'm thinking of completely giving up on PD as a viable option for this project.
--
Nick Rothwell Cassiel.com Limited nick@cassiel.com www.cassiel.com systems - composition - installation - performance
Hi Miller,
OK, had some sleep, trying again...
Well, "pd -rme" and "./configure --enable-rme" are both to use Ritch's driver. But "rme96xx" Is Guenter Geiger's newer, OSS driver for RME. Therefore you don't have to flag ./configure and the correct invocation is indeed "pd -inchannels 8 -outchannels 8"..
Since this seems to contradict other comments on this list, I just want to be absolutely sure I understand what's going on...
(i) Fetch and build the standard PD (I'm on 0.33 patch 2), no RME options;
(ii) Fetch, build and install the rme96xx module (I `insmod' it after soundcore in /etc/rc.d/rc.local).
(iii) run PD with no driver options.
My understanding is that this will run PD using OSS, but with multichannel support via the rme96xx driver. Am I right so far?
I think this bit is the key (and I quote):
OSS: issuing first ADC 'read' ... Pd: system call timed out
...done.
This suggests some problem communicating with the card, or some problem with the OSS stuff in the kernel.
I'm grasping at straws here, but are you sure the es1371 module was loaded _after_ the rme96xx one? Otherwise Pd is trying to open your es1371. Perhaps there's some reason it can't do 8 channels that way.
I've taken the es1371 card out of the machine, to make sure, and the Red Hat configuration tool correctly removed the module from the boot sequence.
Even if not, what does just "pd" do?
"pd" gets 2 input and 2 output channels. "pd -inchannel 8 -outchannel 8" gets 8 ins and 8 outs (using /dev/dsp). But in both cases I get the "system call timed out" and the GUI doesn't respond to anything, suggesting a stuck thread.
I've got a couple of thoughts. One is to do a debug trace through PD and see where the problem is. (The PD thread seems wedged in oss_send_dacs.) The other is to check the hardware: I tried using the Hammerfall under Windows 98 (same hardware, dual-boot) and had problems locking my digital mixer to ADAT sync from the card, so I want to be absolutely sure that the card works under Win98 first. (The mixer locks fine to the OasysPCI card on my Pismo, so the problem is at the PCI end.)
The rmectrl program reports a load of stuff which looks kosher, but I don't know how much this can be trusted...
On 2 Sep 2001, Nick Rothwell wrote:
(i) Fetch and build the standard PD (I'm on 0.33 patch 2), no RME options;
(ii) Fetch, build and install the rme96xx module (I `insmod' it after soundcore in /etc/rc.d/rc.local).
Test the card with a simple soundapp, like #> play blah.wav ... If this works, you have at least a working card/driver ...
(iii) run PD with no driver options.
My understanding is that this will run PD using OSS, but with multichannel support via the rme96xx driver. Am I right so far?
I think this bit is the key (and I quote):
OSS: issuing first ADC 'read' ... Pd: system call timed out ...done.
if the card works (checked with the play command), then it is still possible that the open call is to slow on your hardware, ..
change in s_linux.c: oss_open_audio(..) occurences of sys_setalarm(1000000); to sys_setalarm(5000000);
and recompile, ...
The rmectrl program reports a load of stuff which looks kosher, but I don't know how much this can be trusted...
if the rmectrl works there is a good chance that your hardware works. .. There will be a day when I will find the time to improve the rmectrl program ...
TO check if the card loaded correctly you can issue a
dmesg
which will show you a short message about loading the rme96xx module ..
(... sorry for the delay, but I was sort of busy lately ..)
Guenter
Hello Guenter,
Thanks for the feedback. My suspicion at this stage is the hardware: some problem with the PCI bus on an old-ish machine I've built for an installation. As I recall, even the Sound Blaster card wouldn't work when the Hammerfall was present, but the Sound Blaster works fine when the Hammerfall is removed. For now we'll just go with Sound Blaster analogue stereo, since we're under a tight deadline, and will look again at the Hammerfall when there's less time pressure.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
hi list, hi iohannes
gemplus, gem 0.84-6 and pd 0.34 built fine (debian 2.2). gem runs ok but when i create any of the four gemplus objects i get:
error: can't load abstraction within itself
any ideas?
thanks lu
-
guenter geiger -
ludwig zeininger -
Miller Puckette -
Nick Rothwell