All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonas Petersen <jnsptrsn1@gmail.com>
To: Pavel Hofman <pavel.hofman@ivitera.com>
Cc: alsa-devel@alsa-project.org
Subject: Re: M-Audio Delta 1010LT: S/PDIF clock source not working
Date: Thu, 11 Apr 2013 09:23:54 +0200	[thread overview]
Message-ID: <5166650A.7080506@gmail.com> (raw)
In-Reply-To: <516423F0.9020409@ivitera.com>

Am 09.04.2013 16:21, schrieb Pavel Hofman:
> On 9.4.2013 00:56, Jonas Petersen wrote:
>> Am 07.04.2013 22:35, schrieb Alan Horstmann:
>>> On Sunday 07 April 2013 18:03, Gabriel M. Beddingfield wrote:
>>>> On 04/06/2013 05:52 PM, Jonas Petersen wrote:
>>>>> It seems it's related to the ICE1712... I now tried the Audiophile
>>>>> 2496.
>>>>> Same behaviour! There is no way to clock from external (S/PDIF). The
>>>>> 'Multi Track Internal Clock Default' setting will always override the
>>>>> external clock rate and mess up the capturing.
>>>> Well, it /should/ work -- according to the 1010's manual.  I'll bet it's
>>>> some register setting that's missing on the ice1712 -- but I have no
>>>> access to the specs/datasheets/schematics on these things.
>>>>
>>>> I wonder -- did this ever work on Linux?
>> Yes! I while ago I was doing stuff with the Delta 66 and things were
>> fine. That was back with Ubuntu 10.04 and Alsa 1.0.22 and also 1.0.23.
>> I just grabbed an old Ubuntu 10.04 ISO which contains Alsa 1.0.22 and
>> live booted it on my machine. Tests show that it's working as expected
>> with the 1010LT: It's properly externally clocked.
>>
>>
>>> However I do seem to remember some relatively recent changes related
>>> to external wordclock on the 1010; maybe it has been broken?
>> I found commit b8b1a4cb6842fb33769be1ad636f062d31d588c3 from Jan 17
>> 23:20:03 2011. It's a patch on delta.c and it's regarding a clock issue
>> (though not exactly wordclock). I reverted that patch and recompiled but
>> no success.
>>
>> I'm going to continue later on that topic. At least there must have been
>> some change that broke it since 1.0.23.
> Hi Jonas,
>
> first - did you try with "Multi Track Rate Locking" on and off? This
> control is a bit clumsy.

I havn't tried so far, but did now. It has been 'off' all the time, but 
setting it to 'on' makes no difference.


> How about
> http://git.alsa-project.org/?p=alsa-kmirror.git;a=blobdiff;f=pci/ice1712/ice1712.c;h=fb61943fc4dc9631853d76fa2524cd51880bcd9a;hp=c7cff6f8168a2d0159a0df20ea2c97550dafd6db;hb=b125bc8783367e3eb65312039a29bf2f25e931db;hpb=3e3911eb86fc7016c9cfef0525b9568c3106c4e4
> ?
>
> It is from about that time.

Yeah, that's getting closer I guess. When I undo that commit, then it's 
possible to capture with the external rate!

*But*... I'm afraid it's still clocked from internal. Because it's not 
capturing cleanly. It's got glitches sometimes (without having xruns).


> pro_rate_locked is both when locked explicitly as well as when switched
> to spdif clock
>
> http://git.alsa-project.org/?p=alsa-kmirror.git;a=blob;f=pci/ice1712/ice1712.c;h=5be2e120a14e25a03744b873e690f765eecb9545;hb=ec10d549379e10b38fe365fbf6bc13bf44f965ac#l133

How strange.. but there's probably a reason for rate locking on spdif 
clock..

> Please check ice1712 register values, specifically MT RATE to make sure
> ice1712 is switched to internal clocks when it should be clocked
> externally instead (
> http://ftp.sunet.se/pub/Linux/alsa/manuals/icensemble/envy24.pdf ). Or
> just dump  ice1712 in proc here, I will check with the datasheet.

I'm not sure, is it 'Codec' in ice1712 that's 'PCI60: System 
Configuration Register' in the datasheet? From that the clock source 
would be '00: XIN2: 22.5792MHz crystal (44.1kHz*512)'.

Here's my ice1712:
-------------------------------------------
M Audio Delta 1010LT at 0xd040, irq 20

EEPROM:
   Subvendor        : 0x12143bd6
   Size             : 29 bytes
   Version          : 1
   Codec            : 0x1f
   ACLink           : 0x80
   I2S ID           : 0x72
   S/PDIF           : 0x3
   GPIO mask        : 0x4
   GPIO state       : 0x7e
   GPIO direction   : 0xfb
   AC'97 main       : 0x0
   AC'97 pcm        : 0x0
   AC'97 record     : 0x0
   AC'97 record src : 0x44
   DAC ID #0        : 0x3
   DAC ID #1        : 0x3
   DAC ID #2        : 0x3
   DAC ID #3        : 0x3
   ADC ID #0        : 0x3
   ADC ID #1        : 0x3
   ADC ID #2        : 0x3
   ADC ID #3        : 0x3
   Extra #28        : 0x0

Registers:
   PSDOUT03         : 0x0000
   CAPTURE          : 0x00000000
   SPDOUT           : 0x0000
   RATE             : 0x10
   GPIO_DATA        : 0x5a
   GPIO_WRITE_MASK  : 0x04
   GPIO_DIRECTION   : 0xfb
-------------------------------------------

With "Multi Track Internal Clock" on "IEC958 Input" the content of 
ice1712 has not changed at all, no matter what ("Default") rate I select 
or rate I capture. Also before and after reverting the patch it's the 
same content.

When I change "Multi Track Internal Clock" to some specific rate then 
(only) RATE and GPIO_DATA change. E.g.:

44100:
   RATE             : 0x08
   GPIO_DATA        : 0x52

48000:
   RATE             : 0x00
   GPIO_DATA        : 0x52

96000:
   RATE             : 0x07
   GPIO_DATA        : 0x53

For some reason GPIO_DATA will now stay on 0x53 when I switch to "IEC958 
Input" (before it was fixed on 0x5a).


> Unfortunately there is no /proc register dump coded for cs8427 yet. If
> you want to investigate further, you can add it to i2c/cs8427.c in a
> manner similar to e.g.
> http://git.alsa-project.org/?p=alsa-kmirror.git;a=blob;f=i2c/other/ak4114.c;h=fdf3c1b65e388414c995a597ef2b351b4ec2a220;hb=HEAD#l451

I'm working on it...


- Jonas

  reply	other threads:[~2013-04-11  7:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-05 15:34 M-Audio Delta 1010LT: S/PDIF clock source not working Jonas Petersen
2013-04-07  0:52 ` Jonas Petersen
2013-04-07 17:03   ` Gabriel M. Beddingfield
2013-04-07 20:35     ` Alan Horstmann
2013-04-08 22:56       ` Jonas Petersen
2013-04-09 14:21         ` Pavel Hofman
2013-04-11  7:23           ` Jonas Petersen [this message]
2013-04-12 14:53           ` Jonas Petersen
2013-04-15  7:35             ` Pavel Hofman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5166650A.7080506@gmail.com \
    --to=jnsptrsn1@gmail.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=pavel.hofman@ivitera.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.