Re: [Jackit-devel] Real-world reports on two Delta 1010LTs/ice1712 synched?

Re: [Jackit-devel] Real-world reports on two Delta 1010LTs/ice1712 synched?

[Doug McLain]

Yes, I know about the spdif to word clock bug.  This is why I resorted 
to Windows, to get a feel for the *correct* behavior.  After knowing how 
it is supposed to work, I found that word clock i/o in Linux on the 
1010LT is inoperative.  I broke out a scope on the word clock output, 
and signals are present.  I also confirmed that my bnc cables are all 
good by using them in windows.  Finally, I connected the word clock 
output of my EZBus digital mixer to the word clock in of a 1010LT (in a 
machine with just one card), and in no way could I get any sign from the 
card that an external word clock signal was present.  Again, I repeated 
all of these tests in windows to confirm.  So again, it appears that 
envy24control is still hosed.  As I said in the last email, I remembered 
that about 2 years ago I had the exact same problem with envy24control.
I have 5 1010LT's and have had 4 of them involved in this testing over 
the past few days, just in case there is any concern about hardware 
problems.  Also, everything works correctly in windows.  I keep a 
windows machine handy for reference, very useful for times like these.

Regarding the new asoundrc, its not needed for me, all my spdif i/o 
already works, but only when I click on 'Word Clock' with an spdif 
output from another source coming in.  To make this very clear, I have 
no need for spdif, and am not interested in using it as a clock source, 
or for audio.  The reason for all of this was strictly for 
troubleshooting purposes.

So once again, the one and only setup that works for me at the moment, 
is connecting spdif outputs from my ezbus digital mixer to the inputs of 
each delta, and pressing *Word Clock* (after pressing spdif first, of 
course because of the glitch) on each card.  They now become synced, 
like they should be in 'SPDIF In' mode.  Also it works if I only connect 
the ezbus's spdif out to the spdif in of card 0, then card 0 spdif out 
-> card 1 spdif in.  This works just like if both cards were connected 
to the ezbus's 2 spdif outputs.  I also put audio signals on all the 
spdif outs and ins of both cards to see if they all worked, all worked 
well.  Again, all this only if *Word Clock* (after pressing spdif first, 
of course because of the glitch) on both cards (or 1 card if im working 
with a single card) is pressed.  I hope there is no more confusion here. 
  I am posting this to alsa-devel as well, since envy24control (or the 
relevent snd_ctl_* facilities in the ice1712 driver) is still broken.

All of the envy24control code treats the 1010 and 1010LT equally, so if 
there is a difference, its in the hardware of the devices:

if (card_eeprom.subvendor == ICE1712_SUBDEVICE_DELTA1010 ||
	    card_eeprom.subvendor == ICE1712_SUBDEVICE_DELTA1010LT) {
		delta specific stuff here...

I find it strange that the envy24control patch does not change anything 
for me.  What exactly was your issue with envy24control before applying 
that patch?

So any 1010 users and 1010LT users that have the ability to do a simple 
test of connecting an external bnc word clock signal to the word clock 
in connector of their card, and see if the 'Locked' label changes to 'no 
signal'?  Yes the text is backwards, no big deal, its the change thats 
important.  Perhaps conduct the test once before and once after applying 
the patch from john's website:

http://www.sound-man.co.uk/linuxaudio/envy24control-wcstatus-patch-1.0.10

Doug
--
http://nostar.net/

John Rigg wrote:
> On Mon, Dec 26, 2005 at 03:59:15PM -0500, Doug McLain wrote:
> 
>>As I said before, the reason for using SPDIF is, nothing else works.  In
>>Linux, word clock input does not work at all!
> 
> 
> When you tried the word clock input did you try clicking on the S/PDIF button
> in envy24control before clicking the word clock button? I found the word
> clock button didn't work until I did that (I've reported it to ALSA
> bugtrack).
> 
> If you did that and it still didn't work, the only reason I can think
> of is that there is enough difference between a Delta 1010 and the
> 1010LT to make it behave differently. On my system both word clock and
> S/PDIF sync now work, but I haven't read the envy24control source code in
> enough detail yet to say if yours should be the same.
> 
> John


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Jackit-devel mailing list
Jackit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-devel




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: [Jackit-devel] Real-world reports on two Delta 1010LTs/ice1712 synched?

[Doug McLain]

Yes, I know about the spdif to word clock bug.  This is why I resorted 
to Windows, to get a feel for the *correct* behavior.  After knowing how 
it is supposed to work, I found that word clock i/o in Linux on the 
1010LT is inoperative.  I broke out a scope on the word clock output, 
and signals are present.  I also confirmed that my bnc cables are all 
good by using them in windows.  Finally, I connected the word clock 
output of my EZBus digital mixer to the word clock in of a 1010LT (in a 
machine with just one card), and in no way could I get any sign from the 
card that an external word clock signal was present.  Again, I repeated 
all of these tests in windows to confirm.  So again, it appears that 
envy24control is still hosed.  As I said in the last email, I remembered 
that about 2 years ago I had the exact same problem with envy24control.
I have 5 1010LT's and have had 4 of them involved in this testing over 
the past few days, just in case there is any concern about hardware 
problems.  Also, everything works correctly in windows.  I keep a 
windows machine handy for reference, very useful for times like these.

Regarding the new asoundrc, its not needed for me, all my spdif i/o 
already works, but only when I click on 'Word Clock' with an spdif 
output from another source coming in.  To make this very clear, I have 
no need for spdif, and am not interested in using it as a clock source, 
or for audio.  The reason for all of this was strictly for 
troubleshooting purposes.

So once again, the one and only setup that works for me at the moment, 
is connecting spdif outputs from my ezbus digital mixer to the inputs of 
each delta, and pressing *Word Clock* (after pressing spdif first, of 
course because of the glitch) on each card.  They now become synced, 
like they should be in 'SPDIF In' mode.  Also it works if I only connect 
the ezbus's spdif out to the spdif in of card 0, then card 0 spdif out 
-> card 1 spdif in.  This works just like if both cards were connected 
to the ezbus's 2 spdif outputs.  I also put audio signals on all the 
spdif outs and ins of both cards to see if they all worked, all worked 
well.  Again, all this only if *Word Clock* (after pressing spdif first, 
of course because of the glitch) on both cards (or 1 card if im working 
with a single card) is pressed.  I hope there is no more confusion here. 
  I am posting this to alsa-devel as well, since envy24control (or the 
relevent snd_ctl_* facilities in the ice1712 driver) is still broken.

All of the envy24control code treats the 1010 and 1010LT equally, so if 
there is a difference, its in the hardware of the devices:

if (card_eeprom.subvendor == ICE1712_SUBDEVICE_DELTA1010 ||
	    card_eeprom.subvendor == ICE1712_SUBDEVICE_DELTA1010LT) {
		delta specific stuff here...

I find it strange that the envy24control patch does not change anything 
for me.  What exactly was your issue with envy24control before applying 
that patch?

So any 1010 users and 1010LT users that have the ability to do a simple 
test of connecting an external bnc word clock signal to the word clock 
in connector of their card, and see if the 'Locked' label changes to 'no 
signal'?  Yes the text is backwards, no big deal, its the change thats 
important.  Perhaps conduct the test once before and once after applying 
the patch from john's website:

http://www.sound-man.co.uk/linuxaudio/envy24control-wcstatus-patch-1.0.10

Doug
--
http://nostar.net/

John Rigg wrote:
> On Mon, Dec 26, 2005 at 03:59:15PM -0500, Doug McLain wrote:
> 
>>As I said before, the reason for using SPDIF is, nothing else works.  In
>>Linux, word clock input does not work at all!
> 
> 
> When you tried the word clock input did you try clicking on the S/PDIF button
> in envy24control before clicking the word clock button? I found the word
> clock button didn't work until I did that (I've reported it to ALSA
> bugtrack).
> 
> If you did that and it still didn't work, the only reason I can think
> of is that there is enough difference between a Delta 1010 and the
> 1010LT to make it behave differently. On my system both word clock and
> S/PDIF sync now work, but I haven't read the envy24control source code in
> enough detail yet to say if yours should be the same.
> 
> John


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: [Jackit-devel] Real-world reports on two Delta 1010LTs/ice1712 synched?

[Doug McLain]

Doug McLain wrote:

> All of the envy24control code treats the 1010 and 1010LT equally

...  Except for one crucial line:

hardware.c:165:if (card_eeprom.subvendor != ICE1712_SUBDEVICE_DELTA1010)

And this is where my problem begins, and yours, well, never starts. :)

I first blindly added ICE1712_SUBDEVICE_DELTA1010LT to the if statement 
hoping for a quick fix, but no luck.  I discovered that the 
snd_ctl_elem_value "Word Clock Status" is only defined for the 1010 and 
not the 1010LT in the ice1712 driver code.

Further digging (starting on line 620 of 
alsa-kernel/pci/ice1712/delta.c) reveals that the 1010 has 2 seperate 
gen purpose i/o registers for the word clock. One appears to be read 
only, for checking status, and the other is the one to set the state. 
The LT has one, that is either meant to serve both checking status and 
setting state, or some driver code is missing.

static snd_kcontrol_new_t snd_ice1712_delta1010_wordclock_select 
__devinitdata =
ICE1712_GPIO(SNDRV_CTL_ELEM_IFACE_MIXER, "Word Clock Sync", 0, 
ICE1712_DELTA_WORD_CLOCK_SELECT, 1, 0);
static snd_kcontrol_new_t snd_ice1712_delta1010lt_wordclock_select 
__devinitdata =
ICE1712_GPIO(SNDRV_CTL_ELEM_IFACE_MIXER, "Word Clock Sync", 0, 
ICE1712_DELTA_1010LT_WORDCLOCK, 1, 0);
static snd_kcontrol_new_t snd_ice1712_delta1010_wordclock_status 
__devinitdata =
ICE1712_GPIO(SNDRV_CTL_ELEM_IFACE_MIXER, "Word Clock Status", 0, 
ICE1712_DELTA_WORD_CLOCK_STATUS, 1, SNDRV_CTL_ELEM_ACCESS_READ | 
SNDRV_CTL_ELEM_ACCESS_VOLATILE);



I'm going to experiment blindly to try to determine the answer to this 
by reading and writing all over the snd_ctl_elem"Word Clock Sync", 
hoping for something good to happen.  If any of the alsa ice1712/delta 
driver gurus are listening, please chime in.

Doug
--
http://nostar.net/


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: [Jackit-devel] Real-world reports on two Delta 1010LTs/ice1712 synched?

[Doug McLain]

Doug McLain wrote:

> All of the envy24control code treats the 1010 and 1010LT equally

...  Except for one crucial line:

hardware.c:165:if (card_eeprom.subvendor != ICE1712_SUBDEVICE_DELTA1010)

And this is where my problem begins, and yours, well, never starts. :)

I first blindly added ICE1712_SUBDEVICE_DELTA1010LT to the if statement 
hoping for a quick fix, but no luck.  I discovered that the 
snd_ctl_elem_value "Word Clock Status" is only defined for the 1010 and 
not the 1010LT in the ice1712 driver code.

Further digging (starting on line 620 of 
alsa-kernel/pci/ice1712/delta.c) reveals that the 1010 has 2 seperate 
gen purpose i/o registers for the word clock. One appears to be read 
only, for checking status, and the other is the one to set the state. 
The LT has one, that is either meant to serve both checking status and 
setting state, or some driver code is missing.

static snd_kcontrol_new_t snd_ice1712_delta1010_wordclock_select 
__devinitdata =
ICE1712_GPIO(SNDRV_CTL_ELEM_IFACE_MIXER, "Word Clock Sync", 0, 
ICE1712_DELTA_WORD_CLOCK_SELECT, 1, 0);
static snd_kcontrol_new_t snd_ice1712_delta1010lt_wordclock_select 
__devinitdata =
ICE1712_GPIO(SNDRV_CTL_ELEM_IFACE_MIXER, "Word Clock Sync", 0, 
ICE1712_DELTA_1010LT_WORDCLOCK, 1, 0);
static snd_kcontrol_new_t snd_ice1712_delta1010_wordclock_status 
__devinitdata =
ICE1712_GPIO(SNDRV_CTL_ELEM_IFACE_MIXER, "Word Clock Status", 0, 
ICE1712_DELTA_WORD_CLOCK_STATUS, 1, SNDRV_CTL_ELEM_ACCESS_READ | 
SNDRV_CTL_ELEM_ACCESS_VOLATILE);



I'm going to experiment blindly to try to determine the answer to this 
by reading and writing all over the snd_ctl_elem"Word Clock Sync", 
hoping for something good to happen.  If any of the alsa ice1712/delta 
driver gurus are listening, please chime in.

Doug
--
http://nostar.net/


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Jackit-devel mailing list
Jackit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-devel




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: [Alsa-devel] Re: Real-world reports on two Delta 1010LTs/ice1712 synched?

[John Rigg]

On Mon, Dec 26, 2005 at 09:34:39PM -0500, Doug McLain wrote:
> All of the envy24control code treats the 1010 and 1010LT equally, so if 
> there is a difference, its in the hardware of the devices:
> 
> if (card_eeprom.subvendor == ICE1712_SUBDEVICE_DELTA1010 ||
> 	    card_eeprom.subvendor == ICE1712_SUBDEVICE_DELTA1010LT) {
> 		delta specific stuff here...
> 
> I find it strange that the envy24control patch does not change anything 
> for me.  What exactly was your issue with envy24control before applying 
> that patch?

With 2.6.14 or later kernel, starting envy24control (from alsa-tools-1.0.10)
from xterm resulted in a slew of error messages saying "Unable to determine
word clock status" scrolling off the xterm. The patch fixed that. Maybe that
only happens with the 1010 not the 1010LT. It's possible that with the broken
word clock on the 1010LT it wasn't even trying to determine word clock
status so it didn't trigger the bug.

John


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Re: [Jackit-devel] Real-world reports on two Delta 1010LTs/ice1712 synched?

[Doug McLain]

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


> 
> With 2.6.14 or later kernel, starting envy24control (from alsa-tools-1.0.10)
> from xterm resulted in a slew of error messages saying "Unable to determine
> word clock status" scrolling off the xterm. The patch fixed that. Maybe that
> only happens with the 1010 not the 1010LT. It's possible that with the broken
> word clock on the 1010LT it wasn't even trying to determine word clock
> status so it didn't trigger the bug.
> 
> John

I asked that before I started studying the mixer and driver code 
closely.  I now have a good understanding of what the patch does, and 
why the 1010LT isnt working.  I also don't need any tests done by anyone 
that I was asking for.

It looks like the driver is the root of the problem.  There doesnt 
appear to currently be any facility provided for the 1010LT to set and 
check word clock as the master clock source, and SPDIF In only works by 
accident.

#define ICE1712_DELTA_1010LT_WORDCLOCK 0x80	/* sample clock source: 0 = 
Word Clock Input, 1 = S/PDIF Input ??? */

Doesn't appear to be correct, as SPDIF Input works wether I send a 1 or 
a 0 to the word_clock_sync snd_ctl_elem.  I'm going to keep plugging 
away at this when I get time to get back on it. For now, here's a patch 
that should fix the problem of having to press spdif before word clock. 
  If it does work for you on the regular 1010, then the comments for 
both the 1010 and 1010lt are backwards (where 0 = word clock and 1 = spdif).

Doug
--
http://nostar.net/


[-- Attachment #2: envy24control-wcselect.diff --]
[-- Type: text/x-patch, Size: 626 bytes --]

Index: hardware.c
===================================================================
RCS file: /cvsroot/alsa/alsa-tools/envy24control/hardware.c,v
retrieving revision 1.17
diff -u -r1.17 hardware.c
--- hardware.c  5 Dec 2005 21:03:06 -0000       1.17
+++ hardware.c  27 Dec 2005 20:47:24 -0000
@@ -128,6 +128,7 @@
        } else if (!strcmp(what, "SPDIF")) {
                internal_clock_set(13);
        } else if (!strcmp(what, "WordClock")) {
+               internal_clock_set(13); // Hack
                master_clock_word_select(1);
        } else {
                g_print("internal_clock_toggled: %s ???\n", what);

Re: Re: [Jackit-devel] Real-world reports on two Delta 1010LTs/ice1712 synched?

[John Rigg]

On Tue, Dec 27, 2005 at 03:50:02PM -0500, Doug McLain wrote:
> For now, here's a patch 
> that should fix the problem of having to press spdif before word clock. 
>  If it does work for you on the regular 1010, then the comments for 
> both the 1010 and 1010lt are backwards (where 0 = word clock and 1 = spdif).

> Index: hardware.c
> ===================================================================
> RCS file: /cvsroot/alsa/alsa-tools/envy24control/hardware.c,v
> retrieving revision 1.17
> diff -u -r1.17 hardware.c
> --- hardware.c  5 Dec 2005 21:03:06 -0000       1.17
> +++ hardware.c  27 Dec 2005 20:47:24 -0000
> @@ -128,6 +128,7 @@
>         } else if (!strcmp(what, "SPDIF")) {
>                 internal_clock_set(13);
>         } else if (!strcmp(what, "WordClock")) {
> +               internal_clock_set(13); // Hack
>                 master_clock_word_select(1);
>         } else {
>                 g_print("internal_clock_toggled: %s ???\n", what);

The extra line fixes the problem. It makes the buttons behave the way
I'd expect and I can still select either word clock or S/PDIF for sync input.

Thanks,
John


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Re: [Jackit-devel] Real-world reports on two Delta 1010LTs/ice1712 synched?

[Doug McLain]

I'm hard at work trying to fix the word clock selection on the delta 
1010LT.  Can you do me a favor and send the output of cat 
/proc/asound/M1010/ice1712 on your machine?  The heart of the difference 
appears to be in the configuration of the GPIO register.

Thanks
Doug
http://nostar.net/


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Re: [Jackit-devel] Real-world reports on two Delta 1010LTs/ice1712 synched?

[John Rigg]

On Sun, Jan 01, 2006 at 07:55:57AM -0500, Doug McLain wrote:
> I'm hard at work trying to fix the word clock selection on the delta 
> 1010LT.  Can you do me a favor and send the output of cat 
> /proc/asound/M1010/ice1712 on your machine?  The heart of the difference 
> appears to be in the configuration of the GPIO register.

Here's the output from
cat /proc/asound/M1010/ice1712 and
cat /proc/asound/M1010_1/ice1712

These are with jackd running in multi duplex mode at 96kHz, 32 frames,
2 periods with the first card (irq 17) running on its internal clock
and the second card (irq 18) synced to the word clock input.
The only difference between them is in the RATE registers.

John
__________________________________________________________                           

M Audio Delta 1010 at 0xb000, irq 17

EEPROM:
  Subvendor        : 0x121430d6
  Size             : 29 bytes
  Version          : 1
  Codec            : 0x1f
  ACLink           : 0x80
  I2S ID           : 0x1
  S/PDIF           : 0x3
  GPIO mask        : 0x22
  GPIO state       : 0xd0
  GPIO direction   : 0xdd
  AC'97 main       : 0x0
  AC'97 pcm        : 0x0
  AC'97 record     : 0x0
  AC'97 record src : 0x44
  DAC ID #0        : 0x1
  DAC ID #1        : 0x1
  DAC ID #2        : 0x1
  DAC ID #3        : 0x1
  ADC ID #0        : 0x2
  ADC ID #1        : 0x2
  ADC ID #2        : 0x2
  ADC ID #3        : 0x2
  Extra #28        : 0x0

Registers:
  PSDOUT03         : 0x0000
  CAPTURE          : 0x00000000
  SPDOUT           : 0x0000
  RATE             : 0x07

__________________________________________


M Audio Delta 1010 at 0xc000, irq 18

EEPROM:
  Subvendor        : 0x121430d6
  Size             : 29 bytes
  Version          : 1
  Codec            : 0x1f
  ACLink           : 0x80
  I2S ID           : 0x1
  S/PDIF           : 0x3
  GPIO mask        : 0x22
  GPIO state       : 0xd0
  GPIO direction   : 0xdd
  AC'97 main       : 0x0
  AC'97 pcm        : 0x0
  AC'97 record     : 0x0
  AC'97 record src : 0x44
  DAC ID #0        : 0x1
  DAC ID #1        : 0x1
  DAC ID #2        : 0x1
  DAC ID #3        : 0x1
  ADC ID #0        : 0x2
  ADC ID #1        : 0x2
  ADC ID #2        : 0x2
  ADC ID #3        : 0x2
  Extra #28        : 0x0

Registers:
  PSDOUT03         : 0x0000
  CAPTURE          : 0x00000000
  SPDOUT           : 0x0000
  RATE             : 0x17


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: [Alsa-devel] Re: Real-world reports on two Delta 1010LTs/ice1712 synched?

[Pasi Kärkkäinen]

On Tue, Dec 27, 2005 at 03:50:02PM -0500, Doug McLain wrote:
> 
> >
> >With 2.6.14 or later kernel, starting envy24control (from 
> >alsa-tools-1.0.10)
> >from xterm resulted in a slew of error messages saying "Unable to determine
> >word clock status" scrolling off the xterm. The patch fixed that. Maybe 
> >that
> >only happens with the 1010 not the 1010LT. It's possible that with the 
> >broken
> >word clock on the 1010LT it wasn't even trying to determine word clock
> >status so it didn't trigger the bug.
> >
> >John
> 
> I asked that before I started studying the mixer and driver code 
> closely.  I now have a good understanding of what the patch does, and 
> why the 1010LT isnt working.  I also don't need any tests done by anyone 
> that I was asking for.
> 
> It looks like the driver is the root of the problem.  There doesnt 
> appear to currently be any facility provided for the 1010LT to set and 
> check word clock as the master clock source, and SPDIF In only works by 
> accident.
> 
> #define ICE1712_DELTA_1010LT_WORDCLOCK 0x80	/* sample clock source: 0 = 
> Word Clock Input, 1 = S/PDIF Input ??? */
> 
> Doesn't appear to be correct, as SPDIF Input works wether I send a 1 or 
> a 0 to the word_clock_sync snd_ctl_elem.  I'm going to keep plugging 
> away at this when I get time to get back on it. For now, here's a patch 
> that should fix the problem of having to press spdif before word clock. 
>  If it does work for you on the regular 1010, then the comments for 
> both the 1010 and 1010lt are backwards (where 0 = word clock and 1 = spdif).
> 

Doug, 

Have you found out anything? 

- Pasi Kärkkäinen



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click

Re: [Alsa-devel] Re: Real-world reports on two Delta 1010LTs/ice1712 synched?

[Doug McLain]

Good timing, I was just about to give a summary of my findings so far:

First of all, the differences in the 1010LT vs the 1010 that are most 
relevent here, I believe, is the SPDIF i/o chips (cs8413 receiver, 
cs8404 xmitter) used on the 1010 vs the one single transceiver (cs8427) 
used on the 1010LT.  They also use different ADC/DAC's, but at this 
point in the game they dont appear to be relevent to this problem, and 
they appear to be completely functional.

Last night I got my oscope back and took a look at the wordclock output 
signal, first in windows.  As expected, the card outputs at the 
frequency the card is running at, wether its via internal clock, SPDIF 
in, or word clock input.  I checked all three.  Also in windows, SPDIF 
Out works in all 3 modes as well, as it should.

In Linux, There is no word clock output signal nor an SPDIF signal 
unless I either input a word clock signal or an SPDIF signal, and then 
the signal stays at the speed of the input signal, even if I switch to 
various internal clock speeds.  Basically the input clock is just being 
passed thru.  Also, the card will not sync to an input word clock signal 
no way, no how.  It will sync to an spdif signal though.  This is 
actually the only way to get spdif out to work.  On a delta 1010LT in 
Linux, the only way to get SPDIF out, is if there is a valid SPDIF In
signal, and I am clocked off it.

Knowing this, I am currently able to run two delta 1010LT's synced via 
spdif (spdif out of card 1 to spdif of card 2), with JACK (using john 
rigg's asoundrc, alsa-lib, and jack patches), with an external spdif 
signal coming into card 1's SPDIF In from a digital mixer. I did many 
mutitrack recordings of all 16 inputs simultaneously into ardour, 
everything worked great. This just confirms that the only thing keeping 
the 1010LT's from playing nice together is the clock problem.  Otherwise 
they are ready to go.  A possible option while the clock issue remains 
at large, is to use the spdif output from your on board sound card(if so 
equipped) as an spdif source to your first delta.  I gave this about 5 
minutes of my time, and didnt have the best of luck.  I couldnt keep the 
signal coming out of my via82xx alive all the time, etc.  I don't know 
it well enough to use alsamixer, etc and I had to keep xmms running (set 
to use the alsa driver on the via82xx directly) all the time to keep the 
signal alive.  I wasnt too interested in getting it working well like 
this, but it was an idea.

I've been studying the ice1712 alsa driver closely over the past few 
weeks, and comparing all relevent ice1712 control register values in 
windows vs linux (in windows I got ahold of this nice program called 
PCIScope, a dream for reverse engineering pci hardware!) and I think 
(hope) the problem is in the init and configuration of the cs8427 spdif 
transceiver.  There are differences in bit values on the ice1712's GPIO 
data register. So my two areas of concern are deciphering the usage of 
the GPIO register and the cs8427 spdif transceiver. The ice1712 talks to 
the cs8427 over I2C, which isnt as straightforward to read as regular 
i/o registers, so it's more studying ahead.  I am focusing on fixing 
spdif functionality, since the cs8427 datasheet is very clear about 
spdif operation.  I am hoping by fixing regular spdif functionality on 
the ship, word clock will be fixed too. We'll see.

Doug
--
http://nostar.net/


Pasi Kärkkäinen wrote:

> 
> Doug, 
> 
> Have you found out anything? 
> 
> - Pasi Kärkkäinen
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
> _______________________________________________
> Jackit-devel mailing list
> Jackit-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jackit-devel


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click

Re: Re: [Jackit-devel] Real-world reports on two Delta 1010LTs/ice1712 synched?

[Lee Revell]

On Mon, 2006-01-16 at 14:26 -0500, Doug McLain wrote:
> I've been studying the ice1712 alsa driver closely over the past few 
> weeks, and comparing all relevent ice1712 control register values in 
> windows vs linux (in windows I got ahold of this nice program called 
> PCIScope, a dream for reverse engineering pci hardware!) and I think 
> (hope) the problem is in the init and configuration of the cs8427
> spdif transceiver.  There are differences in bit values on the
> ice1712's GPIO data register. So my two areas of concern are
> deciphering the usage of the GPIO register and the cs8427 spdif
> transceiver. The ice1712 talks to the cs8427 over I2C, which isnt as
> straightforward to read as regular i/o registers, so it's more
> studying ahead.  I am focusing on fixing spdif functionality, since
> the cs8427 datasheet is very clear about spdif operation.  I am hoping
> by fixing regular spdif functionality on the ship, word clock will be
> fixed too. We'll see. 

If you get stuck, SoftICE is also an incredibly useful tool for reverse
engineering Windows drivers.

Lee



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Re: [Jackit-devel] Real-world reports on two Delta 1010LTs/ice1712 synched?

[Alan Horstmann]

On Monday 16 January 2006 19:26, Doug McLain wrote:
> Good timing, I was just about to give a summary of my findings so far:
>
> First of all, the differences in the 1010LT vs the 1010 that are most
> relevent here, I believe, is the SPDIF i/o chips (cs8413 receiver,
> cs8404 xmitter) used on the 1010 vs the one single transceiver (cs8427)
> used on the 1010LT.  
>...
>  I am focusing on fixing spdif functionality, 
> Doug

It may be of interest to know that the Terratec DMX6fire, which I have, also 
uses the cs8427, but has both coax and optical SPDIF.  The dig out works OK 
on both, as soon as the snd-ice-1712 is loaded.  It runs without needing any 
'In' clock as you describe with 1010LT.  I can select internal clock freqs 
and detect in my mini-disc recorder 32K, 44.1K, 48K using the coax (and 
optical).  Other rates are not supported by the MD so I can't be sure.  There 
are however some issues with digital in, but by selecting in the right 
sequence this works fine also.

A look at the DMX6fire code therefore may be rewarding?

Alan



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Re: [Jackit-devel] Real-world reports on two Delta 1010LTs/ice1712 synched?

[Alan Horstmann]

On Wednesday 18 January 2006 10:56, I wrote:
>
> A look at the DMX6fire code therefore may be rewarding?
>
Which is in ews.c etc, (not particularly obvious).

Alan



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642