[alsa-devel] M-Audio Delta 1010LT: S/PDIF clock source not working
jnsptrsn1 at gmail.com
Thu Apr 11 09:23:54 CEST 2013
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
>>>>> 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
> 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
How strange.. but there's probably a reason for rate locking on spdif
> 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
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
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
When I change "Multi Track Internal Clock" to some specific rate then
(only) RATE and GPIO_DATA change. E.g.:
RATE : 0x08
GPIO_DATA : 0x52
RATE : 0x00
GPIO_DATA : 0x52
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.
I'm working on it...
More information about the Alsa-devel