Paul,
I've been trying for the last day or so to get some sound out of the
card. Still no luck. The setup does work fine when I boot into Windows.
I've certainly had a few problems on this end, like getting
/etc/asound.state into a funny configuration that had both the on-board
Via chipset and
On Sun, 2003-06-15 at 19:42, Paul Davis wrote:
RME HDSP 9652 (Card #1)
Buffers: capture df00 playback dee0
IRQ: 17 Registers bus: 0xe880 VM: 0xe08e6000
Control register: 0x10080b3
You don't have the correct version of the driver. It would print:
RME Hammerfall HDSP 9652 (Card
On Sun, 2003-06-15 at 20:26, Mark Knecht wrote:
Cool. Something to look for anyway
15 minutes later.
Bingo! OK, so the new driver hadn't gotten moved to the right place. It
seems to be there now. I'm getting sound, but it's full volume and I
don't seem to be able to turn it down.
I have alsamixer up and running, and the volumes turned down to 6 and
it's still screaming loud. Is this like the old driver where the mixer
didn't work at all? Or have I not set the right things?
no, the mixer works, but unfortunately it appears that i didn't test
enough. the code still appears
On Sun, 2003-06-15 at 20:42, Paul Davis wrote:
I have alsamixer up and running, and the volumes turned down to 6 and
it's still screaming loud. Is this like the old driver where the mixer
didn't work at all? Or have I not set the right things?
no, the mixer works, but unfortunately it
OK, I was just remembering Roger Williams telling my some stuff back in
January when I was first trying to get this working (when we didn't know
that the volume controls didn't work) about needing to break
connections. He sent a little script file for the Digiface, but I was
not sure if this was
On Sun, 2003-06-15 at 20:56, Paul Davis wrote:
OK, I was just remembering Roger Williams telling my some stuff back in
January when I was first trying to get this working (when we didn't know
that the volume controls didn't work) about needing to break
connections. He sent a little script file
Paul,
Hi. Thanks for sendign these along. First steps look good. I've
managed to patch things and it does install.
QUESTION - I am not explicitly loading snd-hammerfall-mem, but it is
getting loaded when I start Alsa. Is this correct? I should _not_
explicitly load that file anywhere, but just
QUESTION - I am not explicitly loading snd-hammerfall-mem, but it is
getting loaded when I start Alsa. Is this correct? I should _not_
explicitly load that file anywhere, but just let the driver load it?
it depends on how much physical RAM you have. with lots of RAM, it
will be possible to get
this patch fixes some basic problems with the hdsp driver with respect
to the hdsp9652 card. it also cleans up a few minor issues with naming
in the driver, and slightly rationalizes initialization to involve
the minimum of special-casing for the hdsp9652.
the basic problem with the hdsp9652 was
i just realized that y'all will need this too:
Index: hdsp.h
===
RCS file: /cvsroot/alsa/alsa-kernel/include/hdsp.h,v
retrieving revision 1.1
diff -u -u -r1.1 hdsp.h
--- hdsp.h 7 Apr 2003 15:32:31 - 1.1
+++ hdsp.h
On Wed, 2003-03-05 at 00:22, Paul Davis wrote:
This is a new version of the previous patch, but now also includes:
* use of udelay to force timed loops rather than count-based loops
* fix hdsp_is_9652()
* don't include unnecessary playback mixer controls for Multiface
*
On Wed, 2003-03-05 at 10:02, Thomas Charbonnel wrote:
I'm experiencing complete system lockups with this, in every possible
situation:
* cold boot
* reboot
* post boot module insertion
I did power off the card after updating, so the firmware has to be
loaded.
I get no message from the
If I try to get out of hanged state with the magic sysrq sigterm or
sigkill sequence, I get a flood of snd_printk messages from the
hdsp_fifo_wait(...) function in hdsp.c (line 501), with count = 127.
There are two places where hdsp_fifo_wait is called with count = 127:
hdsp_write_gain (line 550)
in short, i am confused :) :(
but ... help is at hand. i checked my mail archives:
The fifo status counts the number of words waiting in the FIFO. A value of
128 means that the fifo is full. 0 means the fifo is empty.
OK, so this means that
hdsp_fifo_wait (hdsp, 0, some_count);
is
OK, so this means that
hdsp_fifo_wait (hdsp, 0, some_count);
is waiting till the FIFO is empty. by contrast,
hdsp_fifo_wait (hdsp, 127, some_count);
waits till there is 1 word available in the FIFO, meaning that we can
write to it.
How is that we can write to it if it is
On Wed, 2003-03-05 at 15:41, Paul Davis wrote:
i agree. i can't see why it doesn't, unless the LONG_WAIT delays us
for so long that it looks like a freeze ...
It doesn't, as after hitting the magic sysrq sigterm sequence I can see
the hdsp_fifo_wait's snd_printks appear on a regular basis
On Wed, 2003-03-05 at 15:41, Paul Davis wrote:
i agree. i can't see why it doesn't, unless the LONG_WAIT delays us
for so long that it looks like a freeze ...
It doesn't, as after hitting the magic sysrq sigterm sequence I can see
the hdsp_fifo_wait's snd_printks appear on a regular basis
On Wed, 2003-03-05 at 17:34, Paul Davis wrote:
eh? if it returns any non-zero value, we return from
hdsp_initialize_firmware() with -EIO, surely?
You're perfectly right, sorry, I've been mixing things up... :)
I guess a reason for it was that getting all those snd_printks from
hdsp_fifo_wait
This is a new version of the previous patch, but now also includes:
* use of udelay to force timed loops rather than count-based loops
* fix hdsp_is_9652()
* don't include unnecessary playback mixer controls for Multiface
* don't attempt to download firmware to HDSP9652 systems
20 matches
Mail list logo
