Re: [Alsa-devel] hdsp patch
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 the HDSP 9652 in it. That's fixed, but still no sound.
I'm running as root. I've tried both Jack and straight Alsa with
aplay and alsaplayer. Everything acts like I should be getting sound,
but I don't. The Alsa drivers appear to be loaded. Restarting Alsa looks
pretty normal.
alsamixer says everything is turned up to 30. 'M' doesn't seem to
mute or unmute and channels for this card.
Can you clarify - do I need to make any 'connections' through the
HDSP 9652 to get the alsa_pcm:playback_1/2 to be enabled and supplying
audio to my amp? If so, what commands are you using?
I'm attaching asound.state, .asoundrc and a little more info. Let me
know what else you want to see.
Thanks for any pointers you can provide.
Cheers,
Mark
Wizard root # lsmod
Module Size Used byNot tainted
snd-hdsp 32556 3
snd-rawmidi15040 0 [snd-hdsp]
snd-seq-device 4352 0 [snd-rawmidi]
snd-pcm64928 2 [snd-hdsp]
snd-timer 15876 0 [snd-pcm]
snd-hwdep 5216 0 [snd-hdsp]
snd32836 1 [snd-hdsp snd-rawmidi snd-seq-device
snd-pcm snd-timer snd-hwdep]
radeon107972 1
agpgart11920 3 (autoclean)
ide-cd 27080 0 (autoclean)
cdrom 25984 0 (autoclean) [ide-cd]
snd-page-alloc 5404 0 [snd-pcm]
snd-hammerfall-mem 1920 0 [snd-hdsp]
Wizard root #
Wizard root # cat /proc/asound/card0/hdsp
RME HDSP 9652 (Card #1)
Buffers: capture df00 playback dee0
IRQ: 17 Registers bus: 0xe880 VM: 0xe08e6000
Control register: 0x10080b3
Status register: 0x2043088
Status2 register: 0x8041
FIFO status: 0
MIDI1 Output status: 0xff00
MIDI1 Input status: 0xff5e
MIDI2 Output status: 0xff00
MIDI2 Input status: 0xff4b
Buffer Size (Latency): 128 samples (2 periods of 512 bytes)
Hardware pointer (frames): 0
Passthru: no
Line out: on
Firmware version: 1
Sample Clock Source: Internal 44.1 kHz
Preferred Sync Reference: ADAT1
AutoSync Reference: ADAT1
AutoSync Frequency: 44100
System Clock Mode: Master
System Clock Frequency: 44100
IEC958 input: Internal
IEC958 output: Coaxial only
IEC958 quality: Consumer
IEC958 emphasis: off
IEC958 NonAudio: off
IEC958 sample rate: Error flag set
ADAT1: Sync
ADAT2: No Lock
ADAT3: No Lock
SPDIF: No Lock
Word Clock: No Lock
ADAT Sync: No Lock
Wizard root #
On Fri, 2003-06-13 at 21:55, Paul Davis wrote:
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 related to 8 bit versus 32 bit
offsets when addressing the mixer memory. once this was fixed,
everything worked. this driver continues to work fine on my
pci+digiface unit as well.
my apologies for this taking so long - it has taken a long time to ask
RME the right question, and quite a long time to get the
answer. once i got down to it, the fix took 5 minutes!
now we just need to solve the multiface initialization problems :(
--p
state.'' {
control.1 {
comment.access 'read write'
comment.type IEC958
iface PCM
name 'IEC958 Playback Default'
value
''
}
control.2 {
comment.access 'read write inactive'
comment.type IEC958
iface PCM
name 'IEC958 Playback PCM Stream'
value
''
}
control.3 {
comment.access read
comment.type IEC958
iface MIXER
name 'IEC958 Playback Con Mask'
value
Re: [Alsa-devel] hdsp patch
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 #1) Buffers: capture f700 playback f6e0 IRQ: 11 Registers bus: 0xfebb VM: 0xf88af000 Control register: 0x10080f9 Control2 register: 0x800 notice the extra Control2 register printout. 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. (And I only have a few more minutes before my kid goes to sleep. Or tries to...) ;-) 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? The other thing I notice is I only seem to be able to set 24 values in my little script to set volumes. The driver I just replaced allowed me to set all 26. OK, so a lot of progress, but I need to be able to reduce the volume badly!!! What can I send you to see if it's my problem? Also, please answer - do I need to set routing paths through the HDSP FPGA to get the mixer working? Can you supply a script to do that if it's necessary? Thanks, Mark --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp patch
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. (And I only have a few more minutes before my kid goes to sleep. Or tries to...) ;-) 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? The other thing I notice is I only seem to be able to set 24 values in my little script to set volumes. The driver I just replaced allowed me to set all 26. OK, so a lot of progress, but I need to be able to reduce the volume badly!!! What can I send you to see if it's my problem? Also, please answer - do I need to set routing paths through the HDSP FPGA to get the mixer working? Can you supply a script to do that if it's necessary? Thanks, Mark BTW: Wizard rme9652 # cat /proc/asound/card0/hdsp RME Hammerfall HDSP 9652 (Card #1) Buffers: capture de40 playback de20 IRQ: 17 Registers bus: 0xe880 VM: 0xe4cf7000 Control register: 0x10080de Control2 register: 0x800 Status register: 0x2040008 Status2 register: 0x8061 FIFO status: 0 MIDI1 Output status: 0xff00 MIDI1 Input status: 0xff00 MIDI2 Output status: 0xff00 MIDI2 Input status: 0xff00 Buffer Size (Latency): 8192 samples (2 periods of 32768 bytes) Hardware pointer (frames): 0 Passthru: no Line out: on Firmware version: 1 Sample Clock Source: Internal 48 kHz Preferred Sync Reference: ADAT1 AutoSync Reference: ADAT1 AutoSync Frequency: 48000 System Clock Mode: Master System Clock Frequency: 48000 IEC958 input: Internal IEC958 output: Coaxial only IEC958 quality: Consumer IEC958 emphasis: off IEC958 NonAudio: off IEC958 sample rate: Error flag set ADAT1: Sync ADAT2: No Lock ADAT3: No Lock SPDIF: No Lock Word Clock: No Lock ADAT Sync: No Lock Wizard rme9652 # --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp patch
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 to be not quite right - there's a tricky detail that you can only write 32 bit values to the mixer, but each mixer element is 16 bits, so you always have to write the one you want to modify, plus its neighbour. looks like i don't have that quite right yet. The other thing I notice is I only seem to be able to set 24 values in my little script to set volumes. The driver I just replaced allowed me to set all 26. i'll check on that. probably just a mistake on my part about the number of channels (i tend to forget the s/pdif outs). Also, please answer - do I need to set routing paths through the HDSP FPGA to get the mixer working? no. the mixer is (dis|en)abled by flipping a control register bit. if its on, its on. what needs work is the hdsp_write_gain() function. --p --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp patch
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 appears that i didn't test
enough. the code still appears to be not quite right - there's a
tricky detail that you can only write 32 bit values to the mixer, but
each mixer element is 16 bits, so you always have to write the one you
want to modify, plus its neighbour. looks like i don't have that
quite right yet.
OK, well I'll stay tuned for possible patches and testing whatever you
need. Thanks.
If it makes any difference in simplifying your initial testing, I have
my speakers hooked to the HDSP9652 ADAT1 port, using channels 1 2. I'm
not using any other channels in that group, or any other ADAT outputs as
of yet.
If you think some other outputs do work (in terms of modifying the
volumes, let me know and I'll switch to them.
I don't suppose there is any .asoundrc magic that could reduce the
volume automagically in Alsa itself instead of in the driver? (A JAck
volume control?) ;-)
The other thing I notice is I only seem to be able to set 24 values in
my little script to set volumes. The driver I just replaced allowed me
to set all 26.
i'll check on that. probably just a mistake on my part about the
number of channels (i tend to forget the s/pdif outs).
I figured as much. No problem right now.
Also, please answer - do I need to set routing paths through the HDSP
FPGA to get the mixer working?
no. the mixer is (dis|en)abled by flipping a control register bit. if
its on, its on. what needs work is the hdsp_write_gain() function.
--p
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 required, or just something he kept around for test
purposes:
#!/bin/bash
ADAT1=0 1 2 3 4 5 6 7
ADAT2=8 9 10 11 12 13 14 15
ADAT3=16 17 18 19 20 21 22 23
SPDIF=24 25
function disconnect () {
for output in $@; do
input=0
while [ $input -le 25 ]; do
echo -n .
amixer cset numid=5 $input,$output,0 /dev/null
input=$((input+1))
done
done
echo
}
echo -n Disconnecting ADAT1 outputs
disconnect $ADAT1
echo -n Disconnecting ADAT2 outputs
disconnect $ADAT2
echo -n Disconnecting ADAT3 outputs
disconnect $ADAT3
echo -n Disconnecting SPDIF output
disconnect $SPDIF
Thanks,
Mark
---
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp patch
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 required, or just something he kept around for test purposes: no, this doesn't do anything except write values to the mixer, and its the function inside the driver that does this which is broken. --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp patch
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 for the Digiface, but I was not sure if this was required, or just something he kept around for test purposes: no, this doesn't do anything except write values to the mixer, and its the function inside the driver that does this which is broken. Thanks for the explanation. I'll watch the list for updates. Cheers, Mark --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp patch
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 let the driver load it? Also, I seem to have had some problems with the second patch you sent. It didn't apply. I'm sure it's just me. IT was so simple so I just typed it into the file. Were these sent as attachments, or as text within the email? Hopefully I'll get some sound later today. Currently nothing is hooked up to the card, so that will take a while to switch over as everything is quite buried right now. Thanks, Mark Wizard alsa-driver # lsmod Module Size Used byNot tainted snd-hdsp 32556 0 snd-rawmidi15040 0 [snd-hdsp] snd-seq-device 4352 0 [snd-rawmidi] snd-pcm64928 0 [snd-hdsp] snd-timer 15876 0 [snd-pcm] snd-page-alloc 5404 0 [snd-pcm] snd-hwdep 5216 0 [snd-hdsp] snd32836 0 [snd-hdsp snd-rawmidi snd-seq-device snd-pcm snd-timer snd-hwdep] snd-hammerfall-mem 1920 0 [snd-hdsp] radeon107972 1 agpgart11920 3 (autoclean) ide-cd 27080 0 (autoclean) cdrom 25984 0 (autoclean) [ide-cd] Wizard alsa-driver # Wizard card0 # more hdsp RME HDSP 9652 (Card #1) Buffers: capture dee0 playback df00 IRQ: 17 Registers bus: 0x2880 VM: 0xe08e6000 Control register: 0x100805e Status register: 0x280 Status2 register: 0x8701 FIFO status: 0 MIDI1 Output status: 0xff00 MIDI1 Input status: 0xff3a MIDI2 Output status: 0xff00 MIDI2 Input status: 0xff39 Buffer Size (Latency): 8192 samples (2 periods of 32768 bytes) Hardware pointer (frames): 0 Passthru: no Line out: on Firmware version: 1 Sample Clock Source: Internal 32 kHz Preferred Sync Reference: ADAT1 AutoSync Reference: None AutoSync Frequency: 0 System Clock Mode: Master System Clock Frequency: 32000 IEC958 input: Internal IEC958 output: Coaxial only IEC958 quality: Consumer IEC958 emphasis: off IEC958 NonAudio: off IEC958 sample rate: Error flag set ADAT1: No Lock ADAT2: No Lock ADAT3: No Lock SPDIF: No Lock Word Clock: No Lock ADAT Sync: No Lock Wizard card0 # On Fri, 2003-06-13 at 21:55, Paul Davis wrote: 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. --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp patch
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 the required physically contiguous RAM for a long time after booting. with less RAM, you need to get the memory module loaded early, before other parts of booting have fragmented the kernel's physical memory map so much that its no longer possible. Also, I seem to have had some problems with the second patch you sent. It didn't apply. I'm sure it's just me. IT was so simple so I just typed it into the file. Were these sent as attachments, or as text within the email? just text. typing it in is fine, too (its how i did it!) --p --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] hdsp patch
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 related to 8 bit versus 32 bit
offsets when addressing the mixer memory. once this was fixed,
everything worked. this driver continues to work fine on my
pci+digiface unit as well.
my apologies for this taking so long - it has taken a long time to ask
RME the right question, and quite a long time to get the
answer. once i got down to it, the fix took 5 minutes!
now we just need to solve the multiface initialization problems :(
--p
Index: hdsp.c
===
RCS file: /cvsroot/alsa/alsa-kernel/pci/rme9652/hdsp.c,v
retrieving revision 1.35
diff -u -u -r1.35 hdsp.c
--- hdsp.c 30 Apr 2003 11:53:23 - 1.35
+++ hdsp.c 14 Jun 2003 04:47:27 -
@@ -75,6 +75,8 @@
#define DIGIFACE_DS_CHANNELS 14
#define MULTIFACE_SS_CHANNELS18
#define MULTIFACE_DS_CHANNELS14
+#define H9652_DS_CHANNELS24
+#define H9652_SS_CHANNELS24
/* Write registers. These are defined as byte-offsets from the iobase value.
*/
@@ -84,7 +86,7 @@
#define HDSP_controlRegister 64
#define HDSP_interruptConfirmation 96
#define HDSP_outputEnable 128
-#define HDSP_jtagReg 256
+#define HDSP_control2Reg 256
#define HDSP_midiDataOut0 352
#define HDSP_midiDataOut1 356
#define HDSP_fifoData 368
@@ -120,7 +122,7 @@
#define HDSP_IO_EXTENT 5192
-/* jtag register bits */
+/* control2 register bits */
#define HDSP_TMS0x01
#define HDSP_TCK0x02
@@ -133,6 +135,7 @@
#define HDSP_VERSION_BIT 0x100
#define HDSP_BIGENDIAN_MODE 0x200
#define HDSP_RD_MULTIPLE0x400
+#define HDSP_9652_ENABLE_MIXER 0x800
#define HDSP_S_PROGRAM (HDSP_PROGRAM|HDSP_CONFIG_MODE_0)
#define HDSP_S_LOAD(HDSP_PROGRAM|HDSP_CONFIG_MODE_1)
@@ -358,15 +361,16 @@
hdsp_midi_t midi[2];
struct tasklet_struct midi_tasklet;
int precise_ptr;
- u32 control_register; /* cached value */
+ u32 control_register; /* cached value */
+ u32 control2_register; /* cached value */
u32 creg_spdif;
u32 creg_spdif_stream;
- char *card_name;/* digiface/multiface */
+ char *card_name; /* digiface/multiface */
HDSP_IO_Type io_type; /* ditto, but for code use */
unsigned shortfirmware_rev;
unsigned shortstate; /* stores state bits */
u32 firmware_cache[24413]; /* this helps recover from
accidental iobox power failure */
- size_tperiod_bytes; /* guess what this is */
+ size_tperiod_bytes; /* guess what this is */
unsigned char ds_channels;
unsigned char ss_channels; /* different for
multiface/digiface */
void *capture_buffer_unaligned; /* original buffer addresses
*/
@@ -452,7 +456,7 @@
/* prototypes */
static int __devinit snd_hdsp_create_alsa_devices(snd_card_t *card, hdsp_t *hdsp);
static int __devinit snd_hdsp_create_pcm(snd_card_t *card, hdsp_t *hdsp);
-static inline int snd_hdsp_initialize_input_enable (hdsp_t *hdsp);
+static inline int snd_hdsp_enable_io (hdsp_t *hdsp);
static inline void snd_hdsp_initialize_midi_flush (hdsp_t *hdsp);
static inline void snd_hdsp_initialize_channels (hdsp_t *hdsp);
static inline int hdsp_fifo_wait(hdsp_t *hdsp, int count, int timeout);
@@ -460,18 +464,6 @@
static int hdsp_autosync_ref(hdsp_t *hdsp);
static int snd_hdsp_set_defaults(hdsp_t *hdsp);
-static inline int hdsp_is_9652 (hdsp_t *hdsp)
-{
- switch (hdsp-firmware_rev) {
- case 0x64:
- case 0x65:
- case 0x68:
- return 1;
- default:
- return 0;
- }
-}
-
static inline int hdsp_playback_to_output_key (hdsp_t *hdsp, int in, int out)
{
switch (hdsp-firmware_rev) {
@@ -504,12 +496,15 @@
static inline int hdsp_check_for_iobox (hdsp_t *hdsp)
{
+ return 0;
+#if 0
if (hdsp_read (hdsp, HDSP_statusRegister) HDSP_ConfigError) {
snd_printk (Hammerfall-DSP: no Digiface or Multiface connected!\n);
hdsp-state = ~HDSP_FirmwareLoaded;
return -EIO;
}
return 0;
+#endif
}
static int snd_hdsp_load_firmware_from_cache(hdsp_t *hdsp) {
@@ -521,7 +516,7 @@
[Alsa-devel] hdsp patch part II
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 14 Jun 2003 05:08:59 -
@@ -24,6 +24,7 @@
typedef enum {
Digiface,
Multiface,
+ H9652,
Undefined,
} HDSP_IO_Type;
---
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp patch, version II
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 * don't attempt to download firmware to HDSP9652 systems (its not the right thing to do, apparently) --p 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 driver. No timeout ever occurs. (I left the machine hanging for at least 10 minutes) My system: Kernel 2.4.20 ck3 Alsa-driver 9.0rc8 + hdsp patch II applied Cardbus + multiface Thomas --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp patch, version II
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 driver. No timeout ever occurs. (I left the machine hanging for at least 10 minutes) My system: Kernel 2.4.20 ck3 Alsa-driver 9.0rc8 + hdsp patch II applied Cardbus + multiface Thomas 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) hdsp_initialize_firmware (line 3013) I checked with the last working code I have, but can't find the problem. I tried to switch back to the pre-udelay code in hdsp_fifo_wait, but the problem is still here. Any idea ? Thomas --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp patch, version II
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) hdsp_initialize_firmware (line 3013) I checked with the last working code I have, but can't find the problem. I tried to switch back to the pre-udelay code in hdsp_fifo_wait, but the problem is still here. we used to have this problem before i added udelay, but it would manifest differently because the delay wasn't there. it seems that some (all?) setups with either the cardbus or the multiface (or both) show this behaviour. the code in question is waiting till there are 127 words available in the command FIFO. to be honest, i never understood this code. other places where we wait, we wait till there are zero words available, which seems nonsensical to me. the idea is that the FIFO only processes so many words per sample-clock-cycle, and so it can get filled easily. it can hold a maximum of 128 words. in short, i am confused :) :( --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp patch, version II
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 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. this doesn't help explain why we sometimes fail to see this condition being met. any insights? --p --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp patch, version II
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 full ?
we never test for it being full. the tests are either for = 0 (EMPTY)
or = 127 (at least 1 word available).
In the case the above question is stupid, and the fifo being full
meaning we can write to it, we have the following code in
snd_hdsp_initialize_firmware anyway:
for (i = 0; i 24413; ++i) {
hdsp_write(hdsp, HDSP_fifoData, firmware_ptr[i]);
if (hdsp_fifo_wait (hdsp, 127, HDSP_LONG_WAIT)) {
snd_printk (timeout during firmware loading\n);
return -EIO;
}
}
yes, but before we enter that loop we checked to make sure that the
FIFO was empty. so the loop is really writing a word, then waiting for
a word to be available.
this doesn't help explain why we sometimes fail to see this condition
being met. any insights?
Is it really that the condition is not being met ?
It should gracefully fail. That's what timeouts are for. If the
condition fails, then the driver should fail to instantiate, and the
boot process should go on. The problem is that we have a freeze.
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 ...
--p
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp patch, version II
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 (looks like
120 bpm). This is not surprising as HDSP_LONG_WAIT is supposed to last
500ms. In fact the timeout should occur 24413/2/60 = circa 186 minutes
later. The code is :
for (i = 0; i 24413; ++i) {
hdsp_write(hdsp, HDSP_fifoData, firmware_ptr[i]);
if (hdsp_fifo_wait (hdsp, 127, HDSP_LONG_WAIT)) {
snd_printk (timeout during firmware loading\n);
return -EIO;
}
}
If hdsp_fifo_wait fails and returns -1 we go through the whole loop,
thus effectively waiting almost 3 hours.
Thomas
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp patch, version II
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 (looks like
120 bpm). This is not surprising as HDSP_LONG_WAIT is supposed to last
500ms. In fact the timeout should occur 24413/2/60 = circa 186 minutes
later. The code is :
for (i = 0; i 24413; ++i) {
hdsp_write(hdsp, HDSP_fifoData, firmware_ptr[i]);
if (hdsp_fifo_wait (hdsp, 127, HDSP_LONG_WAIT)) {
snd_printk (timeout during firmware loading\n);
return -EIO;
}
}
If hdsp_fifo_wait fails and returns -1 we go through the whole loop,
thus effectively waiting almost 3 hours.
eh? if it returns any non-zero value, we return from
hdsp_initialize_firmware() with -EIO, surely?
--p
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp patch, version II
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 sounded like having hdsp_fifo_wait being called from a loop. Do you have any clue I could work on ? Thomas --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] hdsp patch, version II
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 (its
not the right thing to do, apparently)
--p
Index: hdsp.c
===
RCS file: /cvsroot/alsa/alsa-kernel/pci/rme9652/hdsp.c,v
retrieving revision 1.26
diff -u -u -r1.26 hdsp.c
--- hdsp.c 4 Mar 2003 16:47:35 - 1.26
+++ hdsp.c 4 Mar 2003 22:29:59 -
@@ -23,7 +23,6 @@
#include sound/driver.h
#include linux/delay.h
#include linux/interrupt.h
-#include linux/init.h
#include linux/slab.h
#include linux/pci.h
@@ -42,13 +41,14 @@
#include multiface_firmware.dat
#include digiface_firmware.dat
+#include multiface_firmware_rev11.dat
+#include digiface_firmware_rev11.dat
static int index[SNDRV_CARDS] = SNDRV_DEFAULT_IDX; /* Index 0-MAX */
static char *id[SNDRV_CARDS] = SNDRV_DEFAULT_STR; /* ID for this card */
static int enable[SNDRV_CARDS] = SNDRV_DEFAULT_ENABLE_PNP; /* Enable this card */
static int precise_ptr[SNDRV_CARDS] = { [0 ... (SNDRV_CARDS-1)] = 0 }; /* Enable
precise pointer */
static int line_outs_monitor[SNDRV_CARDS] = { [0 ... (SNDRV_CARDS-1)] = 0}; /* Send
all inputs/playback to line outs */
-static int force_firmware[SNDRV_CARDS] = { [0 ... (SNDRV_CARDS-1)] = 0}; /* Force
firmware reload */
MODULE_PARM(index, 1- __MODULE_STRING(SNDRV_CARDS) i);
MODULE_PARM_DESC(index, Index value for RME Hammerfall DSP interface.);
@@ -65,19 +65,17 @@
MODULE_PARM(line_outs_monitor,1- __MODULE_STRING(SNDRV_CARDS) i);
MODULE_PARM_DESC(line_outs_monitor, Send all input and playback streams to line outs
by default.);
MODULE_PARM_SYNTAX(line_outs_monitor, SNDRV_ENABLED , SNDRV_BOOLEAN_FALSE_DESC);
-MODULE_PARM(force_firmware,1- __MODULE_STRING(SNDRV_CARDS) i);
-MODULE_PARM_DESC(force_firmware, Force a reload of the I/O box firmware);
-MODULE_PARM_SYNTAX(force_firmware, SNDRV_ENABLED , SNDRV_BOOLEAN_FALSE_DESC);
MODULE_AUTHOR(Paul Davis [EMAIL PROTECTED]);
MODULE_DESCRIPTION(RME Hammerfall DSP);
MODULE_LICENSE(GPL);
MODULE_CLASSES({sound});
-MODULE_DEVICES({{RME,Hammerfall-DSP}});
+MODULE_DEVICES({{RME Hammerfall-DSP},
+ {RME HDSP-9652}});
typedef enum {
Digiface,
- Multiface
-} HDSP_Type;
+ Multiface,
+} HDSP_IO_Type;
#define HDSP_MAX_CHANNELS26
#define DIGIFACE_SS_CHANNELS 26
@@ -123,9 +121,9 @@
#define HDSP_playbackPeakLevel 4096 /* 26 * 32 bit values */
#define HDSP_inputPeakLevel 4224 /* 26 * 32 bit values */
-#define HDSP_outputPeakLevel4100 /* 26 * 32 bit values */
+#define HDSP_outputPeakLevel4352 /* 26 * 32 bit values */
#define HDSP_playbackRmsLevel 4612 /* 26 * 64 bit values */
-#define HDSP_inputRmsLevel 4884 /* 26 * 64 bit values */
+#define HDSP_inputRmsLevel 4868 /* 26 * 64 bit values */
#define HDSP_IO_EXTENT 5192
@@ -282,15 +280,11 @@
#define HDSP_SelSyncRef_WORD (HDSP_SelSyncRef2)
#define HDSP_SelSyncRef_ADAT_SYNC (HDSP_SelSyncRef0|HDSP_SelSyncRef2)
-/* FIFO wait times, defined in terms of loops on readl() */
+/* FIFO wait times, defined in terms of 1/10ths of msecs */
-#define HDSP_LONG_WAIT 4
-#define HDSP_SHORT_WAIT 100
+#define HDSP_LONG_WAIT 5000
+#define HDSP_SHORT_WAIT 30
-/* Computing addresses for adjusting gains */
-
-#define INPUT_TO_OUTPUT_KEY(in,out) ((64 * (out)) + (in))
-#define PLAYBACK_TO_OUTPUT_KEY(chn,out) ((64 * (out)) + 32 + (chn))
#define UNITY_GAIN 32768
#define MINUS_INFINITY_GAIN 0
@@ -335,42 +329,43 @@
};
struct _hdsp {
- spinlock_t lock;
+ spinlock_t lock;
snd_pcm_substream_t *capture_substream;
snd_pcm_substream_t *playback_substream;
-hdsp_midi_t midi[2];
- int precise_ptr;
- u32 control_register;/* cached value */
- u32 creg_spdif;
- u32 creg_spdif_stream;
- char *card_name; /* digiface/multiface */
-HDSP_Type type; /* ditto, but for code use */
- size_t period_bytes; /* guess what this is */
- unsigned char ds_channels;
- unsigned char ss_channels; /* different for multiface/digiface */
- void *capture_buffer_unaligned; /* original buffer addresses */
- void *playback_buffer_unaligned; /* original buffer addresses */
- unsigned char *capture_buffer; /* suitably aligned address */
- unsigned char *playback_buffer; /* suitably aligned address */
- dma_addr_t capture_buffer_addr;
- dma_addr_t playback_buffer_addr;
- pid_t capture_pid;
- pid_t playback_pid;
- int running;
-int passthru; /* non-zero if doing pass-thru */
- int
