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: Tue, 29 Jan 2013 10:39:24 +0100 [thread overview]
Message-ID: <510798CC.3080006@ivitera.com> (raw)
In-Reply-To: <5107188F.3060001@gmail.com>
On 29.1.2013 01:32, Jonas Petersen wrote:
> Am 28.01.2013 13:36, schrieb Pavel Hofman:
>> Right, looks like a bug in snd_ak4114_create. Nevertheless the 7th reg
>> RCS0 is read-only, writing anything bogus should not affect the
>> operation.
> Ok. I once filled it with a zero with no effect.
That is what I thought. We will fix the code though.
>
>> What does the ak4114 regs dump in /proc/asound... dir of your
>> audiophile192 look like? The snd_ak4114_proc_regs_read method reads real
>> values from the regs.
> You know what, there ist no ak4114... See the attached
> Audiophile192-proc.txt. That's everything in proc.
> Before I was doing some printk's in snd_ak4114_create() and
> snd_ak4114_reg_write() and other places. They ended up in kern.log.
> Then was also fiddling around with the configuration (ak4114_init_vals)
> which didn't change anything in the capture behaviour. I even entirely
> removed the snd_ak4114_create() call. It was still just capturing spdif
> 6 dB to loud with the shifted signals as described before.
> So the ak4114 code is not in operation at all?
First, please tell us your alsa version (/proc/asound/version)
Please move the ak4114 init call from the controls section to the init
section (just like in juli.c) and test:
diff --git a/sound/pci/ice1712/revo.c b/sound/pci/ice1712/revo.c
index 7641080..bb6c82a 100644
--- a/sound/pci/ice1712/revo.c
+++ b/sound/pci/ice1712/revo.c
@@ -562,6 +562,9 @@ static int revo_init(struct snd_ice1712 *ice)
ice);
if (err < 0)
return err;
+ err = ap192_ak4114_init(ice);
+ if (err < 0)
+ return err;
/* unmute all codecs */
snd_ice1712_gpio_write_bits(ice, VT1724_REVO_MUTE,
@@ -597,9 +600,6 @@ static int revo_add_controls(struct snd_ice1712 *ice)
err = snd_ice1712_akm4xxx_build_controls(ice);
if (err < 0)
return err;
- err = ap192_ak4114_init(ice);
- if (err < 0)
- return err;
break;
}
return 0;
>
>
>>> @Pavel, btw. I also have an ESI Juli@. Spdif capture with this one
>>> does not
>>> work at all (as compared to "kind of working" with the Audiophile 192).
>> Interesting. I am pretty sure I tested the SPDIF input of Juli quite
>> extensively. It even reported the incoming samplerate correctly. How did
>> you test it? Please list amixer contents and ak4114 regs here. Thanks.
>
> I just tried again. The Juli just seem to freeze the whole alsa when I
> try to access the spdif input.
OK, let's do some troubleshooting. Do you have SPDIF signal present at
Juli's input when you try to capture?
Does it lock the moment you open the capture stream (i.e. start the
capturing), or when you switch the rate selector to IEC958-In?
What is your kernel (uname -a)?
Regards,
Pavel.
next prev parent reply other threads:[~2013-01-29 9:39 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 [this message]
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
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=510798CC.3080006@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 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.