HDSP 9652: Input channel corruption

HDSP 9652: Input channel corruption

[Nick Arnold]

[-- Attachment #1: Type: text/plain, Size: 3930 bytes --]

Hello,

(I'm trying a re-post of this question with smaller attachments since the
first message was over-sized and appears to have been blocked in the
moderator's in-tray.  Many appologies if both posts appear -- the content is
identical.)

I've posted previously about problems getting the 9652 up-and-working.  We
overcame the original difficulties but have recently observed another problem
of which we were previously unaware.  I'll detail our setup first then the
symptoms:

Our setup:
----------

A RME Hammerfall HDSP 9652 card on a SMP redhat 9 box.  ALSA 0.9.6 with
Thomas Charbonnel's hdsp driver patch applied.  12 input channels and three
output channels, running at 96KHz 24bit samples.  The output of "uname -a" on
the box says:

    Linux wombat 2.4.20-19.9smp #1 SMP Tue Jul 15 16:45:28 EDT 2003 i686
    athlon i386 GNU/Linux

The amixer settings we use:

     #!/bin/bash
     amixer -c 0 cset numid=11 0
     amixer -c 0 cset numid=13 0
     for i in $(seq 1 26);do
         amixer -c 0 cset name=Chn,index=$i 32768
     done

(ie. sync reference is an external word clock, the card should not use any
internal clock source; and output channels should be turned on.)

I've also attached the contents of /proc/asound/card0/hdsp as hdsp.txt.

The symptoms:
------------

We connect a sine wave to the first 12 channels and record them, and see
three channels -- 0, 4, and 8 -- are "corrupted".  The remaining channels
appear to be well-formed and look as we expect them to.

We tried swapping the card with another identical card and the problem
remained.  We then tried swapping the HDSP 9652 with one of the older DIGI
9652 cards (and re-configuring ALSA) and the problem went-away.  This
indicates a problem with the HDSP 9652 or its driver (and absolves the
cables, AD/DA, and our recording software).

I've attached a plot of channel zero (corrupted) against channel one
(uncorrupted) as data.jpg.  We've determined that the samples on channel zero
are incorrectly ordered.  We've also found a formula that can reorder channel
zero to closely follow the samples of channel one, modulo an expected
difference in gain.

More specifically, it appears as though the following is occuring for (the
96KHz) channel zero:

    48kHz channel 0 samples:    0 2 4 6 ...
    48kHz channel 2 samples:    1 3 5 7 ...

    expected 96KHz channel :    0 1 2 3 4 5 6 7 ...
    observed 96KHz channel :    1 0 3 2 5 4 7 6 ...

(and we presume the same is happening for channels 4 and 8 also.)

It seems most likely to be some code in the driver, or perhaps the mixer is
responsible for this incorrect ordering.

The questions are:

    - could this be a bug, perhaps in the hdsp driver?

    - alternatively, could this be due to some mixer setting that has been
      turned on by default unbeknownst to us?  if so, how can we turn this
      off?

any help much appreciated,

nick.
--
This email is confidential and intended solely for the use of the individual to whom it is addressed.  Any views or opinions presented are solely those of the author and do not necessarily represent those of Nautronix Ltd.

If you are not the intended recipient, you have received this email in error and use, dissemination, forwarding, printing, or copying of this email is strictly prohibited.  If you have received this email in error please contact the sender.

Although our computer systems use active virus protection software, and we take various measures to reduce the risk of viruses being transmitted in e-mail messages and attachments sent from this company, we cannot guarantee that such
e-mail messages and attachments are free from viruses on receipt.  It is a condition of our using e-mail to correspond with you, that any and all liability on our part arising directly or indirectly out of any virus is excluded.
Please ensure that you run virus checking software on all e-mail messages and attachments before reading them.

[-- Attachment #2: hdsp.txt --]
[-- Type: text/plain, Size: 943 bytes --]

RME Hammerfall HDSP 9652 (Card #1)
Buffers: capture f6e00000 playback f6a00000
IRQ: 18 Registers bus: 0xe3000000 VM: 0xf8a07000
Control register: 0x100a0ef
Control2 register: 0x800
Status register: 0x747cf0e
Status2 register: 0xffff8479
FIFO status: 0
MIDI1 Output status: 0xffffff00
MIDI1 Input status: 0xffffff00
MIDI2 Output status: 0xffffff00
MIDI2 Input status: 0xffffff00

Buffer Size (Latency): 8192 samples (2 periods of 32768 bytes)
Hardware pointer (frames): 8192
Passthru: no
Line out: on
Firmware version: 1

Sample Clock Source: AutoSync
Preferred Sync Reference: Word Clock
AutoSync Reference: Word Clock
AutoSync Frequency: 48000
System Clock Mode: Slave
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: Sync
ADAT3: Sync
SPDIF: No Lock
Word Clock: Sync
ADAT Sync: No Lock


[-- Attachment #3: data.jpg --]
[-- Type: image/jpeg, Size: 36626 bytes --]

Re: HDSP 9652: Input channel corruption

[Mark Knecht]

On Wed, 2003-10-08 at 20:12, Nick Arnold wrote:
> The symptoms:
> ------------
> 
> We connect a sine wave to the first 12 channels and record them, and see
> three channels -- 0, 4, and 8 -- are "corrupted".  The remaining channels
> appear to be well-formed and look as we expect them to.

When you say the 'first 12 channels', are you speaking of the
alsa:playback channels, or are you attaching a sine wave the the ADAT
input channels from an external source? I'm not clear on that.

> 
> It seems most likely to be some code in the driver, or perhaps the mixer is
> responsible for this incorrect ordering.

OK, first, I apologize, but Thomas and I never looked at 96KHz
operation, and to the best of my knowledge it was only our debug that
went into the Aug. 27th patch. I think this means you are on new ground.

Thomas and I saw a similar problem at 44.1KHz with ADAT input signals at
one point. In hdspmixer I was getting green audio and yellow peak
information that did not make sense. I do not remember how I came to the
conclusion that there was an ordering problem, but Thomas pretty quickly
found it once I pointed it out. Possibly we only fixed normal speed
operation and missed the double speed equivalent problem.

> 
> The questions are:
> 
>     - could this be a bug, perhaps in the hdsp driver?

I think possibly yes.

> 
>     - alternatively, could this be due to some mixer setting that has been
>       turned on by default unbeknownst to us?  if so, how can we turn this
>       off?

I do not think this is likely, or at least I do not know of anything you
can do.

> 
> any help much appreciated,

I think I'm not helping much...

> 
> nick.




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: HDSP 9652: Input channel corruption

[Nick Arnold]

Hi and thanks for the reply,

> > We connect a sine wave to the first 12 channels and record them, and see
> > three channels -- 0, 4, and 8 -- are "corrupted".  The remaining channels
> > appear to be well-formed and look as we expect them to.
> 
> When you say the 'first 12 channels', are you speaking of the
> alsa:playback channels, or are you attaching a sine wave the the ADAT
> input channels from an external source? I'm not clear on that.

Okay, as usual I'm being ambiguous. :( Sorry.  We attached a signal generator
to the ADAT input channels and used our software to record the first 12
capture channels of the HDSP.  (Also, I'm talking about the first 12 96KHz
channels -- ie. the first 24 48KHz channels.)

> > It seems most likely to be some code in the driver, or perhaps the mixer
> > is responsible for this incorrect ordering.
> 
> OK, first, I apologize, but Thomas and I never looked at 96KHz
> operation, and to the best of my knowledge it was only our debug that
> went into the Aug. 27th patch. I think this means you are on new ground.

No need for you to appologize. :)  As it happens I've managed to be ambiguous
and misleading again: 

The card is running as a slave device (autosync) off a 48KHz clock
source.  Our AD/DA is running in double speed mode so we're getting 96KHz
sampling rate of the raw data.  Our recording software knows we're doing
double speed and does the interleaving.  So, as far as the driver is
concerned we are running at 48KHz.  (And, to be clear: there were no problems
with this setup when we swapped back to a DIGI 9652.)

This might mean we're back on familar ground?
 
> Thomas and I saw a similar problem at 44.1KHz with ADAT input signals at
> one point. In hdspmixer I was getting green audio and yellow peak
> information that did not make sense. I do not remember how I came to the
> conclusion that there was an ordering problem, but Thomas pretty quickly
> found it once I pointed it out. Possibly we only fixed normal speed
> operation and missed the double speed equivalent problem.

This sounds promising, however as I just described we're in normal speed too.
So there seems to still be a problem in normal speed ...

To elaborate on the problem again: seeing corruption on 96KHz channels 0, 4,
and 8.  It appears as though every second sample on these channels is wrong.
Since two 48KHz channels are being combined it seems to indicate that one of
the 48KHz channels is okay, but the other has something wrong.  

One explanation that fits what we've observed is a mystery sample (A) on one
of the channels:

    48KHz channel 1:  A 0 2 4 6 ...
    48KHz channel 0:  1 3 5 7 9 ...

So what we expect (assuming "A" had not been inserted into the stream):

    0 1 2 3 4 5 6 7 ...

But we observe instead:

    A 1 0 3 2 5 4 7 6 9 ...

It feels like an off-by-one bug, but one which apparently only effects every
fourth 96KHz channel -- ie. every fourth pair of 48KHz channels; or, if my
hypothesis above is correct, every eighth 48KHz channel.

> > The questions are:
> >     - could this be a bug, perhaps in the hdsp driver?
>
> I think possibly yes.
> 
> >     - alternatively, could this be due to some mixer setting that has been
> >       turned on by default unbeknownst to us?  if so, how can we turn this
> >       off?
>
> I do not think this is likely, or at least I do not know of anything you
> can do.
> 
> > any help much appreciated,
>
> I think I'm not helping much...

On the contrary.  Its very reassuring to hear we share the same feeling as to
the location of the problem (ie. the driver).  Your help is gratefully
received :)

nick.

--
This email is confidential and intended solely for the use of the individual to whom it is addressed.  Any views or opinions presented are solely those of the author and do not necessarily represent those of Nautronix Ltd.

If you are not the intended recipient, you have received this email in error and use, dissemination, forwarding, printing, or copying of this email is strictly prohibited.  If you have received this email in error please contact the sender.

Although our computer systems use active virus protection software, and we take various measures to reduce the risk of viruses being transmitted in e-mail messages and attachments sent from this company, we cannot guarantee that such
e-mail messages and attachments are free from viruses on receipt.  It is a condition of our using e-mail to correspond with you, that any and all liability on our part arising directly or indirectly out of any virus is excluded.
Please ensure that you run virus checking software on all e-mail messages and attachments before reading them.


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: HDSP 9652: Input channel corruption

[Mark Knecht]

Hi,
   OK, so let me make sure I'm understanding what you're doing. If I
have it right, then comments below might make soem sense. If I have it
wrong, then disregard everything below and help me get it straight.

   My understanding now is that you are just running using standard 48K
operation, but then adding a second layer of software that takes data
from two channels and stitches them together to make what appears to be
a 96KHz signal. The HDSP 9652 can do this in hardware but you are doing
it in software. Is this correct?

   If so, then my thought and suggestions below might be of some help.

Cheers,
Mark

On Fri, 2003-10-10 at 01:55, Nick Arnold wrote:

> Okay, as usual I'm being ambiguous. :( Sorry.  We attached a signal generator
> to the ADAT input channels and used our software to record the first 12
> capture channels of the HDSP.  (Also, I'm talking about the first 12 96KHz
> channels -- ie. the first 24 48KHz channels.)

Cool. So you have 3 ADAT cables coming in, with this 96KHz-ish signal
arriving, and then on the machine you use the output of the Alsa driver
to stitch the data back together to make the 96KHz data stream. Sounds
good.


> The card is running as a slave device (autosync) off a 48KHz clock
> source.  Our AD/DA is running in double speed mode so we're getting 96KHz
> sampling rate of the raw data.  Our recording software knows we're doing
> double speed and does the interleaving.  So, as far as the driver is
> concerned we are running at 48KHz.  (And, to be clear: there were no problems
> with this setup when we swapped back to a DIGI 9652.)

Yes, and this is important I think, in two ways...

> 
> This might mean we're back on familar ground?

I agree. We are back on familiar ground, and possibly ground I or others
could help with.

Clearly, if this is real, then ALL HDSP 9652 users would have an
interest.

> This sounds promising, however as I just described we're in normal speed too.
> So there seems to still be a problem in normal speed ...

And while I don't *think* I have this problem, and I do use channel 8 on
a regular basis, I have not specifically looked for it. I think it would
be very easy for me to do so.

Assume I take an audio stream from Pro Tools and send it to the HDSP
9652 over ADAT, twice and at the same time. I would send this data
stream over channels 8 & 9, and at the same time over 10 & 11. Further
assume that I record these two data streams as separate wave files,
using Ardour or Audacity or whatever application you think makes sense.

Conceptually, I think, if the problem exists these two wave files should
be different, correct? The left channels would be different, but the
right channels would be identical.

Is this correct?

If I was to measure distortion (using some piece of software, I don't
know what, I should see the second copy being identical to my Pro Tools
database, but the first copy would be distorted.

Or, if you provided me with a wave file I could transmit, then I could
provide the output back to you...


> 
> To elaborate on the problem again: seeing corruption on 96KHz channels 0, 4,
> and 8.  It appears as though every second sample on these channels is wrong.
> Since two 48KHz channels are being combined it seems to indicate that one of
> the 48KHz channels is okay, but the other has something wrong.  
> 
> One explanation that fits what we've observed is a mystery sample (A) on one
> of the channels:
> 
>     48KHz channel 1:  A 0 2 4 6 ...
>     48KHz channel 0:  1 3 5 7 9 ...
> 
> So what we expect (assuming "A" had not been inserted into the stream):
> 
>     0 1 2 3 4 5 6 7 ...
> 
> But we observe instead:
> 
>     A 1 0 3 2 5 4 7 6 9 ...

It does look like an 'off-by-one' type bug, especially if the Hammerfall
did not exhibit the same problem.

Question #1 - I only use 44.1KHz operation. It seems unlikely, but is
there any chance that this changes based on those two frequencies?

Observation - On my system, I output All of my Pro Tools audio over ADAT
to my Linux box on channels 8 & 9, and then the HDSP 9652 forwards it
(in hardware) to channels 0&1 for speakers, and 2&3 for headphones. I
spend most of my time listening on headphones. I have thought this
soulds better than the DigiDesign converters. I would have thought, if I
was having the problem you describe, that it would sound worse.

Question #2 - I have two Linux boxes here, one with a Hammerfall Lite,
and the other with an HDSP 9652. Can you record something using the
Hammerfall on your end, send me a file, and tell me how to transmit this
from my Hammerfall Lite into the HDSP 9652? 

If I then recorded it and got the same problem, that might be
interesting.

Or maybe there are easier ways to do the same things, such as my Pro
Tools dual recording experiment.

Comments?

> >
> > I think I'm not helping much...
> 
> On the contrary.  Its very reassuring to hear we share the same feeling as to
> the location of the problem (ie. the driver).  Your help is gratefully
> received :)
> 
> nick.

I'm very willing to try a few experiments over the weekend. Contact me
off list to discuss what you might like me to try.

Cheers,
Mark




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: HDSP 9652: Input channel corruption

[Mark Knecht]

[-- Attachment #1: Type: text/plain, Size: 1581 bytes --]

Nick,
   Following on from my other response to you, I do not see the problem
you are speaking of. (Again, assuming I understand what you are saying
the problem is.) The attacked .png file (I hope small enough to be
accepted by the reflector - it's about 27K) shows the audio on channels
8, 10, 12 & 14. This assumes your channel numbering of 0-23 and is all
even (left ) channels on the ADAT 2 input to the HDSP 9652.

   I ran a quick test this evening by creating a session in Pro Tools
where I have a single stereo audio track. I then routed the track (via
sends) to the 4 ADAT stereo output pairs:

Pro Tools	HDSP 9652 in

ADAT 1-2	ADAT-2 8,9
ADAT 3-4	ADAT-2 10,11
ADAT 5-6	ADAT-2 12,13
ADAT 7-8	ADAT-2 14,15

   I recorded the four incoming stereo pairs using Audacity and then
deleted the 9,11,13 & 15 inputs from the display for this picture. 

   As you can see from this display, there is not obvious different
between the 4 channels. Channel 8 appears to be identical to channels
10, 12 & 14. I think that if there was the ordering problem you were
seeing it should be evident in this photo, but I'm not seeing it.

   (This was true for 9,11,13 & 15 also...)

   If I've misunderstood the problem you are debugging, let me know and
I'll set up another test. This only too 5 minutes to do, so I'm happy
(and interested!) in helping you debug this, especially if it does turn
out to be a global problem with the card.

   BTW - what firmware does your HDSP 9652 have? I suppose that a
different revision of firmware could certainly account for differences.

Cheers,
Mark

[-- Attachment #2: snap0000.xpm.gz --]
[-- Type: application/x-gzip, Size: 27750 bytes --]

Re: HDSP 9652: Input channel corruption

[alsa-devel]

It sounds to me that the problem Nick Arnold is describing is that in
single-speed (48kS/s) mode, channels 0, 8, and 16 have a 1-sample delay
with respect to all the other channels (using 0-based indexing for
channel numbers here).  This is irrelevant when recording uncorrelated
signals, and subtle when dealing with time-coherent signals
(single-point stereo or Ambisonic for example).  When splitting one
signal across two channels, it is deadly.

The easiest way to check this is to digitally generate a high frequency
sine wave (say 10kHz), and patch it (digitially) to channels 0 and 1 or
8 and 9 (or just go ahead and send it to all the channels).  Make sure
that there are no mismatched delays in whatever tool(s) you use to make
the patches.  Record this signal -- even a few milliseconds is enough.

Then look at it in a waveform editor and zoom way in so you can see the
individual samples.  Check the temporal alignment between track 1 and
track 2 (using 1-based indexing here).  Better yet, subtract the two
tracks.  If all is well the result will be zero; if they are misaligned,
you'll get another 10k sine wave with lower amplitude.

I don't have digital generator in the same setup as my HDSP (independent
of the HDSP that is).  So, I can't do this test without a lot of moving
around.  I am interested in seeing this (possible) problem taken care of.

--Rob



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: HDSP 9652: Input channel corruption

[Paul Davis]

>It sounds to me that the problem Nick Arnold is describing is that in
>single-speed (48kS/s) mode, channels 0, 8, and 16 have a 1-sample delay
>with respect to all the other channels (using 0-based indexing for
>channel numbers here).  This is irrelevant when recording uncorrelated
>signals, and subtle when dealing with time-coherent signals
>(single-point stereo or Ambisonic for example).  When splitting one
>signal across two channels, it is deadly.

i just want to mention the possibility that this is caused by hdsp
firmware. and if it is, and you tried to ask RME about it, and told
them that you were emulating their emulation of 96kHz in your own
software, i doubt you'd get much help from them.

i cannot think of *anything* in the hdsp driver that would have any
effect on this, and i can easily imagine a situation where there was a
1 sample delay between ADAT connectors written into the
(hard|firm)ware (though it does seem unlikely). one thing, for
example, is that i know on the old digi9652, the hardware cannot
guarantee that all channels are operating at the same point in the DMA
buffer, although this should not cause the effect nick has seen.

i really encourage nick to drop (even if its only for testing) his own
double speed operation and try out RME's own stuff (implemented in
their firmware).

--p


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: HDSP 9652: Input channel corruption

[Mark Knecht]

[-- Attachment #1: Type: text/plain, Size: 2233 bytes --]

On Mon, 2003-10-20 at 01:47, Nick Arnold wrote:

> Yes I think so, but I think it'd be easier to look at the recordings at a
> sample-by-sample level.  The process described in this follow-up post is
> pretty much what we've been doing:
> 
>     > From: alsa-devel@robdye.net
>     > To: Alsa-Devel <alsa-devel@lists.sourceforge.net>
>     > Date: Wed, 15 Oct 2003 15:01:01 -0700
>     > Subject: Re: [Alsa-devel] HDSP 9652: Input channel corruption
>     >
>     > ...
>     > Then look at it in a waveform editor and zoom way in so you can see the
>     > individual samples.  Check the temporal alignment between track 1 and
>     > track 2 (using 1-based indexing here).  Better yet, subtract the two
>     > tracks.  If all is well the result will be zero; if they are
>     > misaligned, you'll get another 10k sine wave with lower amplitude.
>     > ...
>     > 
>     > --Rob
> 
> > Or, if you provided me with a wave file I could transmit, then I could
> > provide the output back to you...
> 
> A sine-wave is nice and simple -- do you want us to generate one?
>  

Nick,
   I am not seeing a problem. I set up a sine generator at 12807 Hz in
Pro Tools on PC #1. I transmit this on 8 channels of ADAT and receive it
on the HDSP 9652 in PC #2. I the record all 8 ADAT-2 channels using
Audacity. The attached png file shows ADAT2, channels 1-6. As you can
see, there is no offset on any of the channels. They all look identical.
Channels 7 & 8 were identical also, but I cannot get them to scale down
so that I could get all 8 into a single plot.

   I also transmitted them over ADAT back to Pro Tools and recorded all
8 channels there. All 8 channels were again identical.

   At least for my card I cannot see a problem.

   It would be difficult for me to test the other two ADAT inputs, so
I'm depending (for now) on the idea that you see this problem on ADAT-1,
ADAT-2 & ADAT3.

   I asked earlier, but I think you didn't rely, or I missed it. What
firmware revision are you using on your card? I'm on firmware rev 65.
(Or 101 in decimal.)


Wizard root # lspci
<SNIP>
00:0e.0 Multimedia audio controller: Xilinx Corporation RME Hammerfall
DSP (rev 65)

I hope this helps you with your debug.

Good luck!

Cheers,
Mark

[-- Attachment #2: snap0000.xpm.gz --]
[-- Type: application/x-gzip, Size: 33807 bytes --]

HDSP 9652: Input channel corruption

[Nick Arnold]

[-- Attachment #1: Type: text/plain, Size: 3915 bytes --]

Hello,

(I'm posting this again with smaller attachments since my first attempt was
over-sized and appears to be stuck in the moderator's in-tray.  Many
appologies if both posts appear -- the content is otherwise identical.)

I've posted previously about problems getting the 9652 up-and-working.  We
overcame the original difficulties but have recently observed another problem
of which we were previously unaware.  I'll detail our setup first then the
symptoms:

Our setup:
----------

A RME Hammerfall HDSP 9652 card on a SMP redhat 9 box.  ALSA 0.9.6 with
Thomas Charbonnel's hdsp driver patch applied.  12 input channels and three
output channels, running at 96KHz 24bit samples.  The output of "uname -a" on
the box says:

    Linux wombat 2.4.20-19.9smp #1 SMP Tue Jul 15 16:45:28 EDT 2003 i686
    athlon i386 GNU/Linux

The amixer settings we use:

     #!/bin/bash
     amixer -c 0 cset numid=11 0
     amixer -c 0 cset numid=13 0
     for i in $(seq 1 26);do
         amixer -c 0 cset name=Chn,index=$i 32768
     done

(ie. sync reference is an external word clock, the card should not use any
internal clock source; and output channels should be turned on.)

I've also attached the contents of /proc/asound/card0/hdsp as hdsp.txt.

The symptoms:
------------

We connect a sine wave to the first 12 channels and record them, and see
three channels -- 0, 4, and 8 -- are "corrupted".  The remaining channels
appear to be well-formed and look as we expect them to.

We tried swapping the card with another identical card and the problem
remained.  We then tried swapping the HDSP 9652 with one of the older DIGI
9652 cards (and re-configuring ALSA) and the problem went-away.  This
indicates a problem with the HDSP 9652 or its driver (and absolves the
cables, AD/DA, and our recording software).

I've attached a plot of channel zero (corrupted) against channel one
(uncorrupted) as data.jpg.  We've determined that the samples on channel zero
are incorrectly ordered.  We've also found a formula that can reorder channel
zero to closely follow the samples of channel one, modulo an expected
difference in gain.

More specifically, it appears as though the following is occuring for (the
96KHz) channel zero:

    48kHz channel 0 samples:    0 2 4 6 ...
    48kHz channel 2 samples:    1 3 5 7 ...

    expected 96KHz channel :    0 1 2 3 4 5 6 7 ...
    observed 96KHz channel :    1 0 3 2 5 4 7 6 ...

(and we presume the same is happening for channels 4 and 8 also.)

It seems most likely to be some code in the driver, or perhaps the mixer is
responsible for this incorrect ordering.

The questions are:

    - could this be a bug, perhaps in the hdsp driver?

    - alternatively, could this be due to some mixer setting that has been
      turned on by default unbeknownst to us?  if so, how can we turn this
      off?

any help much appreciated,

nick.
--
This email is confidential and intended solely for the use of the individual to whom it is addressed.  Any views or opinions presented are solely those of the author and do not necessarily represent those of Nautronix Ltd.

If you are not the intended recipient, you have received this email in error and use, dissemination, forwarding, printing, or copying of this email is strictly prohibited.  If you have received this email in error please contact the sender.

Although our computer systems use active virus protection software, and we take various measures to reduce the risk of viruses being transmitted in e-mail messages and attachments sent from this company, we cannot guarantee that such
e-mail messages and attachments are free from viruses on receipt.  It is a condition of our using e-mail to correspond with you, that any and all liability on our part arising directly or indirectly out of any virus is excluded.
Please ensure that you run virus checking software on all e-mail messages and attachments before reading them.

[-- Attachment #2: hdsp.txt --]
[-- Type: text/plain, Size: 943 bytes --]

RME Hammerfall HDSP 9652 (Card #1)
Buffers: capture f6e00000 playback f6a00000
IRQ: 18 Registers bus: 0xe3000000 VM: 0xf8a07000
Control register: 0x100a0ef
Control2 register: 0x800
Status register: 0x747cf0e
Status2 register: 0xffff8479
FIFO status: 0
MIDI1 Output status: 0xffffff00
MIDI1 Input status: 0xffffff00
MIDI2 Output status: 0xffffff00
MIDI2 Input status: 0xffffff00

Buffer Size (Latency): 8192 samples (2 periods of 32768 bytes)
Hardware pointer (frames): 8192
Passthru: no
Line out: on
Firmware version: 1

Sample Clock Source: AutoSync
Preferred Sync Reference: Word Clock
AutoSync Reference: Word Clock
AutoSync Frequency: 48000
System Clock Mode: Slave
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: Sync
ADAT3: Sync
SPDIF: No Lock
Word Clock: Sync
ADAT Sync: No Lock


[-- Attachment #3: data.jpg --]
[-- Type: image/jpeg, Size: 36626 bytes --]