alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Pavel Hofman <pavel.hofman@ivitera.com>
To: Jonas Petersen <jnsptrsn1@gmail.com>
Cc: alsa-devel <alsa-devel@alsa-project.org>
Subject: Re: M-Audio Audiophile 192 (ice1724)'s broken spdif capture
Date: Sat, 02 Feb 2013 11:44:36 +0100	[thread overview]
Message-ID: <510CEE14.2050800@ivitera.com> (raw)
In-Reply-To: <510C6A3C.1000501@gmail.com>

On 2.2.2013 02:22, Jonas Petersen wrote:
> :-)
> 
> I've got some progress here. The AK4114_ADDR was wrong. I changed it
> from 0x02 to 0x00 (according to datasheet).

Fantastic, congrats.

> 
> Now I had some meat in the ak4114 file, but no signal was coming in.
> Then I found that the wrong spdif receiver channel was selected (the
> AK4114 has 4). After selecting the right one (0 instead of 1) I got the
> signal!

Yes, that is a common issue, every card uses a different ak411X input :)
Great you found it.

> 
> Its at the right level (-12dB) and the L/R channels match. But it's
> somehow capturing twice the rate. The 1 kHz come in as 2 kHz. There must
> still be something wrong.

That is actually quite common  too :) Please take a look at the initial
comment section of prodigy192.c where I describe the setup I had to
figure out experimentally. You will have to play with OCKS0/1 of ak4114
(initial chip config in ap192_ak4114_init). Should you not be able to
find the right combination suitable for all incoming samplerates, you
can play with  VT1724_MT_I2S_MCLK_128X of ice1724 (default defined in
ice1724.c:stdclock_set_spdif_clock , can be overriden in
ice->set_spdif_clock for the ap192).

> 
> Regarding the sample rate detection. It seems it's the channel status
> bits that get interpreted by the windows driver. The fs bits from the
> AK4114 seem to be unused. But the channel status definitely changes some
> bits on sample rate changes.

Good catch. Would the FSx registers provide correct info, or
interpretation of the RX Channel status bytes will have to implemented
into ak4114.c:snd_ak4114_rate_get?

Back to the light indicating "sync source" in the windows driver. I
think it is reading status of GPIO06 as you reported "INT0 (pin36) --
GPIO6 pin 58". It would be possible to add a new read-only control for
sync source to revo.c for ap192. It might be useful. Of course a generic
method for ak4114.c would be more suitable but we would have to abstract
the reading method.

Thanks a lot for your effort.

Best regards,

Pavel.

  reply	other threads:[~2013-02-02 10:44 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-26 16:35 M-Audio Audiophile 192 (ice1724)'s broken spdif capture Jonas Petersen
2013-01-26 19:30 ` Jaroslav Kysela
2013-01-26 21:20   ` Pavel Hofman
2013-01-26 22:37     ` Jonas Petersen
2013-01-27 15:49     ` Jonas Petersen
2013-01-28  9:29       ` Jaroslav Kysela
2013-01-28 12:52         ` Pavel Hofman
2013-01-28 21:25           ` Jonas Petersen
2013-01-29  9:44             ` Pavel Hofman
2013-01-31  1:19               ` Jonas Petersen
2013-01-31  9:04                 ` Pavel Hofman
2013-01-31 20:56                   ` Jonas Petersen
2013-01-28 12:36       ` Pavel Hofman
2013-01-29  0:32         ` Jonas Petersen
2013-01-29  9:39           ` Pavel Hofman
2013-01-29 13:10             ` Jonas Petersen
2013-01-30 10:30               ` Pavel Hofman
2013-01-29 19:14             ` Jonas Petersen
2013-01-30 10:26               ` Pavel Hofman
2013-01-30 15:34                 ` Pavel Hofman
2013-01-31  0:29                 ` Jonas Petersen
2013-01-31 10:33                   ` Pavel Hofman
2013-01-31 22:25                     ` Jonas Petersen
2013-02-02  1:22                       ` Jonas Petersen
2013-02-02 10:44                         ` Pavel Hofman [this message]
2013-02-02 22:47                           ` Jonas Petersen
2013-02-04 16:56                             ` Pavel Hofman
2013-02-23 22:13                               ` Jonas Petersen
2013-02-25 11:47                                 ` Pavel Hofman
2013-01-26 21:29   ` Jonas Petersen

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=510CEE14.2050800@ivitera.com \
    --to=pavel.hofman@ivitera.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=jnsptrsn1@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).