[alsa-devel] M-Audio Audiophile 192 (ice1724)'s broken spdif capture
Hi there,
I'm trying to get spdif capture to work properly on the M-Audio Audiophile 192 (VT1724/Envy24HT). It is generally working, but I don't get a clean signal.
I have "Multi Track Internal Clock" set to "IEC958 In" (spdif in). When I capture via Jack, arecord or Audacity I experience the following two phenomenons (always):
1.) The captured signal ends up 6 dB(FS) to loud (200%)! Everything above -6 dB is distorting. A 1 kHz sine test signal at -12 dB (25%) will be captured as -6 dB (50%).
2.) The left and right channels are shifted by one sample! When I feed a 1 kHz test signal (L+R are _exactly_ the same signal), the right channel will be offset by exactly one sample. Zooming into the waveform clearly shows that. Analyzing the signal with a goniometer shows a (slight but obvious) vertical eliptical shape and not the expected single vertical line.
To make sure the hardware actually works fine, I did install a Windows 7 on the exact same machine, installed the drivers from M-Audio and did some recording with audacity. The result is as expected: the -12 dB signal ends up as -12 dB and the left and right channel exactly match each other. So the hardware is willing.
I am running a Lubuntu 12.10 and I'm am able to compile and run the current alsa-driver source with the 3.5.0-22 kernel. I played around a bit with the alsa driver source (e.g. pci/ice1712/ice1724.c, pci/ice1712/revo.c) and I am able to compile and load a modified driver. So far I only was able to make the problem worse though.
I'd now like to ask for some advice on how to approach the problem. I guess the fact that the left and right channel differ - even though they shouldn't - might be a thing to look for. This must be happening at some stage in the capturing. Is there a way to hook in at different places to narrow down what causes this?
Maybe this even already rings somebody's bells?
I'll be glad to deliver more information when needed.
Thanks and regards, Jonas
Date 26.1.2013 17:35, Jonas Petersen wrote:
Hi there,
I'm trying to get spdif capture to work properly on the M-Audio Audiophile 192 (VT1724/Envy24HT). It is generally working, but I don't get a clean signal.
I have "Multi Track Internal Clock" set to "IEC958 In" (spdif in). When I capture via Jack, arecord or Audacity I experience the following two phenomenons (always):
1.) The captured signal ends up 6 dB(FS) to loud (200%)! Everything above -6 dB is distorting. A 1 kHz sine test signal at -12 dB (25%) will be captured as -6 dB (50%).
2.) The left and right channels are shifted by one sample! When I feed a 1 kHz test signal (L+R are _exactly_ the same signal), the right channel will be offset by exactly one sample. Zooming into the waveform clearly shows that. Analyzing the signal with a goniometer shows a (slight but obvious) vertical eliptical shape and not the expected single vertical line.
To make sure the hardware actually works fine, I did install a Windows 7 on the exact same machine, installed the drivers from M-Audio and did some recording with audacity. The result is as expected: the -12 dB signal ends up as -12 dB and the left and right channel exactly match each other. So the hardware is willing.
I am running a Lubuntu 12.10 and I'm am able to compile and run the current alsa-driver source with the 3.5.0-22 kernel. I played around a bit with the alsa driver source (e.g. pci/ice1712/ice1724.c, pci/ice1712/revo.c) and I am able to compile and load a modified driver. So far I only was able to make the problem worse though.
I'd now like to ask for some advice on how to approach the problem. I guess the fact that the left and right channel differ - even though they shouldn't - might be a thing to look for. This must be happening at some stage in the capturing. Is there a way to hook in at different places to narrow down what causes this?
Maybe this even already rings somebody's bells?
I'll be glad to deliver more information when needed.
I believe that there must be a S/PDIF receiver IC somewhere on the board and this IC may be wrongly configured. This IC is not handled in the current ALSA driver at all. Could you look to your board and check the used chips? From pictures on internet, a suspicious IC is in the middle of top on this PCI card. The AKM IC's are for analog audio outputs.
The ICE1724 chip has only serial SPDIF input and SPDIF input clock pins. The input samples should be copied to the DMA without any modifications (no volume control etc.).
Jaroslav
Date 26.1.2013 17:35, Jonas Petersen wrote:
Hi there,
I'm trying to get spdif capture to work properly on the M-Audio Audiophile 192 (VT1724/Envy24HT). It is generally working, but I don't get a clean signal.
I have "Multi Track Internal Clock" set to "IEC958 In" (spdif in). When I capture via Jack, arecord or Audacity I experience the following two phenomenons (always):
1.) The captured signal ends up 6 dB(FS) to loud (200%)! Everything above -6 dB is distorting. A 1 kHz sine test signal at -12 dB (25%) will be captured as -6 dB (50%).
2.) The left and right channels are shifted by one sample! When I feed a 1 kHz test signal (L+R are _exactly_ the same signal), the right channel will be offset by exactly one sample. Zooming into the waveform clearly shows that. Analyzing the signal with a goniometer shows a (slight but obvious) vertical eliptical shape and not the expected single vertical line.
To make sure the hardware actually works fine, I did install a Windows 7 on the exact same machine, installed the drivers from M-Audio and did some recording with audacity. The result is as expected: the -12 dB signal ends up as -12 dB and the left and right channel exactly match each other. So the hardware is willing.
I am running a Lubuntu 12.10 and I'm am able to compile and run the current alsa-driver source with the 3.5.0-22 kernel. I played around a bit with the alsa driver source (e.g. pci/ice1712/ice1724.c, pci/ice1712/revo.c) and I am able to compile and load a modified driver. So far I only was able to make the problem worse though.
I'd now like to ask for some advice on how to approach the problem. I guess the fact that the left and right channel differ - even though they shouldn't - might be a thing to look for. This must be happening at some stage in the capturing. Is there a way to hook in at different places to narrow down what causes this?
Maybe this even already rings somebody's bells?
I'll be glad to deliver more information when needed.
I believe that there must be a S/PDIF receiver IC somewhere on the board and this IC may be wrongly configured.
http://www.nix.ru/autocatalog/m_audio_midiman_sound/34397_2245_draft.jpg reveals it is AK4114, just like in ESI Juli. Its default serial data protocol is not 24bit I2S, the format expected by ICE1724.
It should be feasible to trace the GPIOs from ICE1724 to AK4114 and add the config code.
Regards,
Pavel.
In revo.c I found this:
/* AK4114 support on Audiophile 192 */ /* CDTO (pin 32) -- GPIO2 pin 52 * CDTI (pin 33) -- GPIO3 pin 53 (shared with AK4358) * CCLK (pin 34) -- GPIO1 pin 51 (shared with AK4358) * CSN (pin 35) -- GPIO7 pin 59 */ #define AK4114_ADDR 0x02
I verified these mappings and can confirm that they're correct.
I found one more connection:
INT0 (pin36) -- GPIO6 pin 58
So the complete (?) list with complete pin names on the AK4114 would be:
ICE1724 -> AK4114
GPIO1 -> OCKS1/CCLK/SCL GPIO2 -> CM0/CDTO/CAD1 GPIO3 -> CM1/CDTI/SDA GPIO6 -> INT0 GPIO7 -> OCKS0/CSN/CAD0
I can not rule out that there are more connections! If you think there should be more connections I'll do some more tracing. It is a bit tedious http://www.dict.cc/englisch-deutsch/tedious.html because not all connections can be traced visually. I did that with a multimeter.
If anybody needs datasheets for the VT1724 or AK4114, I have them available.
What would be next? Right now I have no idea how to verify that in the existing code.
- Jonas
2013/1/26 Pavel Hofman pavel.hofman@ivitera.com
http://www.nix.ru/autocatalog/m_audio_midiman_sound/34397_2245_draft.jpg reveals it is AK4114, just like in ESI Juli. Its default serial data protocol is not 24bit I2S, the format expected by ICE1724.
It should be feasible to trace the GPIOs from ICE1724 to AK4114 and add the config code.
Regards,
Pavel.
in ap192_ak4114_init() of revo.c I see this:
---- static const unsigned char ak4114_init_vals[] = { AK4114_RST | AK4114_PWN | AK4114_OCKS0 | AK4114_OCKS1, AK4114_DIF_I24I2S, AK4114_TX1E, AK4114_EFH_1024 | AK4114_DIT | AK4114_IPS(1), 0, 0 }; static const unsigned char ak4114_init_txcsb[] = { 0x41, 0x02, 0x2c, 0x00, 0x00 }; ----
Something wrong here maybe?
I noticed that the ak4114_init_vals array has 6 values but in ap192_ak4114_init() 7 values get written to ak4114.regmap.
@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).
- Jonas
2013/1/26 Pavel Hofman pavel.hofman@ivitera.com
Date 26.1.2013 17:35, Jonas Petersen wrote:
Hi there,
I'm trying to get spdif capture to work properly on the M-Audio Audiophile 192 (VT1724/Envy24HT). It is generally working, but I don't get a clean signal.
I have "Multi Track Internal Clock" set to "IEC958 In" (spdif in). When I capture via Jack, arecord or Audacity I experience the following two phenomenons (always):
1.) The captured signal ends up 6 dB(FS) to loud (200%)! Everything above -6 dB is distorting. A 1 kHz sine test signal at -12 dB (25%) will be captured as -6 dB (50%).
2.) The left and right channels are shifted by one sample! When I feed a 1 kHz test signal (L+R are _exactly_ the same signal), the right channel will be offset by exactly one sample. Zooming into the waveform clearly shows that. Analyzing the signal with a goniometer shows a (slight but obvious) vertical eliptical shape and not the expected single vertical line.
To make sure the hardware actually works fine, I did install a Windows 7 on the exact same machine, installed the drivers from M-Audio and did some recording with audacity. The result is as expected: the -12 dB signal ends up as -12 dB and the left and right channel exactly match each other. So the hardware is willing.
I am running a Lubuntu 12.10 and I'm am able to compile and run the current alsa-driver source with the 3.5.0-22 kernel. I played around a bit with the alsa driver source (e.g. pci/ice1712/ice1724.c, pci/ice1712/revo.c) and I am able to compile and load a modified driver. So far I only was able to make the problem worse though.
I'd now like to ask for some advice on how to approach the problem. I guess the fact that the left and right channel differ - even though they shouldn't - might be a thing to look for. This must be happening at some stage in the capturing. Is there a way to hook in at different places to narrow down what causes this?
Maybe this even already rings somebody's bells?
I'll be glad to deliver more information when needed.
I believe that there must be a S/PDIF receiver IC somewhere on the board and this IC may be wrongly configured.
http://www.nix.ru/autocatalog/m_audio_midiman_sound/34397_2245_draft.jpg reveals it is AK4114, just like in ESI Juli. Its default serial data protocol is not 24bit I2S, the format expected by ICE1724.
It should be feasible to trace the GPIOs from ICE1724 to AK4114 and add the config code.
Regards,
Pavel.
Date 27.1.2013 16:49, Jonas Petersen wrote:
in ap192_ak4114_init() of revo.c I see this:
static const unsigned char ak4114_init_vals[] = { AK4114_RST | AK4114_PWN | AK4114_OCKS0 | AK4114_OCKS1, AK4114_DIF_I24I2S, AK4114_TX1E, AK4114_EFH_1024 | AK4114_DIT | AK4114_IPS(1), 0, 0 }; static const unsigned char ak4114_init_txcsb[] = { 0x41, 0x02, 0x2c, 0x00, 0x00 };
Something wrong here maybe?
I noticed that the ak4114_init_vals array has 6 values but in ap192_ak4114_init() 7 values get written to ak4114.regmap.
Looking to the AK4114 datasheet. I would try the clock mode 2 (CM1=1,CM0=0) and also, check if there is a 11.2896Mhz crystal used for the reference clock (XTL1, XTL0).
Also, the note in revo.c that the input rate reported by AK4114 is unstable, clearly shows that the clock logic is screwed (misconfigured).
Jaroslav
@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).
- Jonas
2013/1/26 Pavel Hofman <pavel.hofman@ivitera.com mailto:pavel.hofman@ivitera.com>
> Date 26.1.2013 17:35, Jonas Petersen wrote: >> Hi there, >> >> I'm trying to get spdif capture to work properly on the M-Audio >> Audiophile >> 192 (VT1724/Envy24HT). It is generally working, but I don't get a clean >> signal. >> >> I have "Multi Track Internal Clock" set to "IEC958 In" (spdif in). When >> I >> capture via Jack, arecord or Audacity I experience the following two >> phenomenons (always): >> >> 1.) The captured signal ends up 6 dB(FS) to loud (200%)! Everything >> above >> -6 dB is distorting. A 1 kHz sine test signal at -12 dB (25%) will be >> captured as -6 dB (50%). >> >> 2.) The left and right channels are shifted by one sample! When I feed a >> 1 >> kHz test signal (L+R are _exactly_ the same signal), the right channel >> will >> be offset by exactly one sample. Zooming into the waveform clearly shows >> that. Analyzing the signal with a goniometer shows a (slight but >> obvious) >> vertical eliptical shape and not the expected single vertical line. >> >> To make sure the hardware actually works fine, I did install a Windows 7 >> on >> the exact same machine, installed the drivers from M-Audio and did some >> recording with audacity. The result is as expected: the -12 dB signal >> ends >> up as -12 dB and the left and right channel exactly match each other. So >> the hardware is willing. >> >> I am running a Lubuntu 12.10 and I'm am able to compile and run the >> current >> alsa-driver source with the 3.5.0-22 kernel. I played around a bit with >> the >> alsa driver source (e.g. pci/ice1712/ice1724.c, pci/ice1712/revo.c) and >> I >> am able to compile and load a modified driver. So far I only was able to >> make the problem worse though. >> >> I'd now like to ask for some advice on how to approach the problem. I >> guess >> the fact that the left and right channel differ - even though they >> shouldn't - might be a thing to look for. This must be happening at some >> stage in the capturing. Is there a way to hook in at different places to >> narrow down what causes this? >> >> Maybe this even already rings somebody's bells? >> >> I'll be glad to deliver more information when needed. > > I believe that there must be a S/PDIF receiver IC somewhere on the board > and this IC may be wrongly configured. http://www.nix.ru/autocatalog/m_audio_midiman_sound/34397_2245_draft.jpg reveals it is AK4114, just like in ESI Juli. Its default serial data protocol is not 24bit I2S, the format expected by ICE1724. It should be feasible to trace the GPIOs from ICE1724 to AK4114 and add the config code. Regards, Pavel.
On 28.1.2013 10:29, Jaroslav Kysela wrote:
Date 27.1.2013 16:49, Jonas Petersen wrote:
in ap192_ak4114_init() of revo.c I see this:
---- static const unsigned char ak4114_init_vals[] = { AK4114_RST | AK4114_PWN | AK4114_OCKS0 | AK4114_OCKS1, AK4114_DIF_I24I2S, AK4114_TX1E, AK4114_EFH_1024 | AK4114_DIT | AK4114_IPS(1), 0, 0 }; static const unsigned char ak4114_init_txcsb[] = { 0x41, 0x02, 0x2c, 0x00, 0x00 }; ----
Something wrong here maybe?
I noticed that the ak4114_init_vals array has 6 values but in ap192_ak4114_init() 7 values get written to ak4114.regmap.
Looking to the AK4114 datasheet. I would try the clock mode 2 (CM1=1,CM0=0) and also, check if there is a 11.2896Mhz crystal used for the reference clock (XTL1, XTL0). Also, the note in revo.c that the input rate reported by AK4114 is unstable, clearly shows that the clock logic is screwed (misconfigured).
The crystal is not used http://www.nix.ru/autocatalog/m_audio_midiman_sound/34397_2245_draft.jpg . IME ak411x cards without the auxiliary Xiling fpga do not provide the independent clock from ak411X and thus cannot report the input rate correctly. That is why I do not make use of the value in the driver (ak->check_flags = AK4114_CHECK_NO_RATE)
Jonas, please could you check if ak4114 pins XTL0/1 (10, 11) are connected to logical high? They should be :)
Regards,
Pavel.
Am 28.01.2013 13:52, schrieb Pavel Hofman:
On 28.1.2013 10:29, Jaroslav Kysela wrote:
Date 27.1.2013 16:49, Jonas Petersen wrote:
in ap192_ak4114_init() of revo.c I see this:
---- static const unsigned char ak4114_init_vals[] = { AK4114_RST | AK4114_PWN | AK4114_OCKS0 | AK4114_OCKS1, AK4114_DIF_I24I2S, AK4114_TX1E, AK4114_EFH_1024 | AK4114_DIT | AK4114_IPS(1), 0, 0 }; static const unsigned char ak4114_init_txcsb[] = { 0x41, 0x02, 0x2c, 0x00, 0x00 }; ----
Something wrong here maybe?
I noticed that the ak4114_init_vals array has 6 values but in ap192_ak4114_init() 7 values get written to ak4114.regmap.
Looking to the AK4114 datasheet. I would try the clock mode 2 (CM1=1,CM0=0) and also, check if there is a 11.2896Mhz crystal used for the reference clock (XTL1, XTL0). Also, the note in revo.c that the input rate reported by AK4114 is unstable, clearly shows that the clock logic is screwed (misconfigured).
The crystal is not used http://www.nix.ru/autocatalog/m_audio_midiman_sound/34397_2245_draft.jpg . IME ak411x cards without the auxiliary Xiling fpga do not provide the independent clock from ak411X and thus cannot report the input rate correctly. That is why I do not make use of the value in the driver (ak->check_flags = AK4114_CHECK_NO_RATE)
Jonas, please could you check if ak4114 pins XTL0/1 (10, 11) are connected to logical high? They should be :)
Physically they're both on ground. I don't know what active state that chip has though.
On 28.1.2013 22:25, Jonas Petersen wrote:
Jonas, please could you check if ak4114 pins XTL0/1 (10, 11) are connected to logical high? They should be :)
Physically they're both on ground. I don't know what active state that chip has though.
Let 's wait until we get the ak4114 register dump file :)
Pavel.
Am 29.01.2013 10:44, schrieb Pavel Hofman:
On 28.1.2013 22:25, Jonas Petersen wrote:
Jonas, please could you check if ak4114 pins XTL0/1 (10, 11) are connected to logical high? They should be :)
Physically they're both on ground. I don't know what active state that chip has though.
Let 's wait until we get the ak4114 register dump file :)
Can't wait. :) I did a quick test in Windows 7. This driver is able to detect the sample rate. If I set the clock source to "spdif in" at the control pannel, then I can see the rate changing when I switch to another rate on the spdif source.
- Jonas
On 31.1.2013 02:19, Jonas Petersen wrote:
Am 29.01.2013 10:44, schrieb Pavel Hofman:
On 28.1.2013 22:25, Jonas Petersen wrote:
Jonas, please could you check if ak4114 pins XTL0/1 (10, 11) are connected to logical high? They should be :)
Physically they're both on ground. I don't know what active state that chip has though.
That would mean the chip is fed 11.2896MHz clock. I do not see any crystal on http://www.nix.ru/autocatalog/m_audio_midiman_sound/34397_2245_draft.jpg . Is it the same card you have, with the crystal position empty? Are you really sure they are not on power supply?
Let 's wait until we get the ak4114 register dump file :)
Can't wait. :)
Did the patch work?
I did a quick test in Windows 7. This driver is able to
detect the sample rate. If I set the clock source to "spdif in" at the control pannel, then I can see the rate changing when I switch to another rate on the spdif source.
Did you test 192kHz and 176,4kHz? The receiver can work in two modes. Either it knows it is fed an independent clock and detects the sample rate precisely, or it simply reads the sample rate from SPDIF preamble of the incoming stream. The mode is select by the XTL0,1 pins. Often the streams do not contain correct information, especially for consumer mode which does not have room for the larger samplerates code. Could you please test both consumer and professional modes, all common samplerates?
Thanks,
Pavel.
Am 31.01.2013 10:04, schrieb Pavel Hofman:
On 31.1.2013 02:19, Jonas Petersen wrote:
Am 29.01.2013 10:44, schrieb Pavel Hofman:
On 28.1.2013 22:25, Jonas Petersen wrote:
Jonas, please could you check if ak4114 pins XTL0/1 (10, 11) are connected to logical high? They should be :)
Physically they're both on ground. I don't know what active state that chip has though.
That would mean the chip is fed 11.2896MHz clock. I do not see any crystal on http://www.nix.ru/autocatalog/m_audio_midiman_sound/34397_2245_draft.jpg . Is it the same card you have, with the crystal position empty? Are you really sure they are not on power supply?
I double-checked. There is zero ohms between these pins and ground (e.g. outer of the spdif connectors, or pin B3 of PCI). The adjacent pins are also on ground which are "VIN" (12), "P/SN" (9) and "IPS1/IIC" (8).
Yeah, pretty much excactly the same card. The crystal position is empty, like on the picture from nix.ru.
I did a quick test in Windows 7. This driver is able to
detect the sample rate. If I set the clock source to "spdif in" at the control pannel, then I can see the rate changing when I switch to another rate on the spdif source.
Did you test 192kHz and 176,4kHz? The receiver can work in two modes. Either it knows it is fed an independent clock and detects the sample rate precisely, or it simply reads the sample rate from SPDIF preamble of the incoming stream.
You mean probably this from the datasheet:
The AK4114 has two methods for detecting the sampling frequency as follows. 1. Clock comparison between recovered clock and X’tal oscillator 2. Sampling frequency information on channel status Those could be selected by XTL1, 0 bits. And the detected frequency is reported on FS3-0 bits.
It is indeed strange. There is an example system design in the datasheet that also has XTL0,1 on ground, but there is a 11 MHz Crystal on XTI and XTO.
The mode is select by the XTL0,1 pins. Often the streams do not contain correct information, especially for consumer mode which does not have room for the larger samplerates code. Could you please test both consumer and professional modes, all common samplerates?
I tested 32, 44.1, 48, 64, 88.2, and 92 kHz with both modes. All rates except 64 kHz are always reliably detected (64 kHz is not in the list of supported frequencies of the chip). They are detected no matter what mode I select (prof/consumer) on both sides, even if they do not match. I tried all combinations.
For these tests I was using an RME Multiface. I guess one can expect correct streams from this device...
Now I checked the spdif signal from a dbx 376 tube channel strip. 44.1, 48, 88.2 and 96 are detected properly.
Ok.. and now I just connected the ESI Juli(a) spdif out to the ap192 spdif in. I'm chaning the internal clock rate in alsamixer. Everything is detected, only 176.4 and 192 result in 88.2 and 96... But this might as well be the Juli failing, doesn't it? I wasn't able to play any sound at these rates neither.
By the way, the Windows 7 "M-Audio Delta Control Panel" has this "sync source" lamp. It is normally green an says "locked" if there is any detected signal. When I change the rate it will become red for a moment and say "rate missmatch", then it will display the detected rate and turn green again.
If I do nothing with a green "locked", it will periodically (about every 6 seconds) show a red "unlocked !" for maybe half a second. Only if I use the signal in a program (e.g. audacity) it will stay "locked" and green.
- Jonas
On 27.1.2013 16:49, Jonas Petersen wrote:
in ap192_ak4114_init() of revo.c I see this:
static const unsigned char ak4114_init_vals[] = { AK4114_RST | AK4114_PWN | AK4114_OCKS0 | AK4114_OCKS1, AK4114_DIF_I24I2S, AK4114_TX1E, AK4114_EFH_1024 | AK4114_DIT | AK4114_IPS(1), 0, 0 }; static const unsigned char ak4114_init_txcsb[] = { 0x41, 0x02, 0x2c, 0x00, 0x00 };
Something wrong here maybe?
These values look correct.
I noticed that the ak4114_init_vals array has 6 values but in ap192_ak4114_init() 7 values get written to ak4114.regmap.
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.
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.
@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.
Pavel.
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.
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?
@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.
See attached Juli files. There _is_ an ak4114 file.
- Jonas
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.
Am 29.01.2013 10:39, schrieb Pavel Hofman:
@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?
Yes, normally I have a 1 kHz Sine/-12dB(25%)/44100 coming in when testing.
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?
I have the Juli card in another machine right now. I'm using the analog out there, which is working fine. It's running a Ubuntu 12.10. 'uname -a' says
Linux rakete 3.5.0-22-generic #34-Ubuntu SMP Tue Jan 8 21:41:11 UTC 2013 i686 i686 i686 GNU/Linux
/proc/asound/version says:
Advanced Linux Sound Architecture Driver Version 1.0.25.
I behaves like this:
If I switch 'Multi Track Internal Clock' to 'IEC958 In', the whole system goes crazy. Not instantly, but when I start alsamixer it locks up (only alsamixer, it can not be killed -9 then). When doing 'ps -aux' it locks up somewhere in the middle of the list. This is all with a signal going in the spdif input. When I reboot (still with signal), the login screen locks up. I can move the mouse, but I can not input the password. Also the background image does not load (which normally does). I can switch to another terminal (e.g. ctrl-alt-f1) and log in. But it will hang sooner or later. No way switch back the 'Multi Track Internal Clock' to a fixed rate. Only if I disconnect the signal from the spdif input and reboot, then I can switch it back and bring the system back to reason. Pew...
- Jonas
On 29.1.2013 14:10, Jonas Petersen wrote:
If I switch 'Multi Track Internal Clock' to 'IEC958 In', the whole system goes crazy. Not instantly, but when I start alsamixer it locks up (only alsamixer, it can not be killed -9 then). When doing 'ps -aux' it locks up somewhere in the middle of the list. This is all with a signal going in the spdif input. When I reboot (still with signal), the login screen locks up. I can move the mouse, but I can not input the password. Also the background image does not load (which normally does). I can switch to another terminal (e.g. ctrl-alt-f1) and log in. But it will hang sooner or later. No way switch back the 'Multi Track Internal Clock' to a fixed rate. Only if I disconnect the signal from the spdif input and reboot, then I can switch it back and bring the system back to reason. Pew...
Thanks a lot for the description. I faintly recall I have heard about this problem once (but never got hold of the reporter to solve). I will take a look, and most likely ask you for more troubleshooting as I do not have the card available. Thanks a lot.
Pavel.
Am 29.01.2013 10:39, schrieb Pavel Hofman:
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)
~$ cat /proc/asound/version Advanced Linux Sound Architecture Driver Version 1.0.25. Compiled on Jan 28 2013 for kernel 3.5.0-22-generic (SMP).
~$ uname -a Linux proto2c 3.5.0-22-generic #34-Ubuntu SMP Tue Jan 8 21:41:11 UTC 2013 i686 athlon i686 GNU/Linux
By the way, I'm compiling a driver snapshot from 24-01-2013. The plain 1.0.25 gives errors.
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;
I did that with no success. Same behaviour, no change, still no ak4114. The only difference I got was:
$ diff ~/Audiophile192-proc-a.txt ~/Audiophile192-proc-b.txt 90c90 < MT05 : 0x08 ---
MT05 : 0x00
I printk'ed a message in ap192_ak4114_init() and it's definitely being called.
Any other ideas?
- Jonas
On 29.1.2013 20:14, Jonas Petersen wrote:
Am 29.01.2013 10:39, schrieb Pavel Hofman:
I did that with no success. Same behaviour, no change, still no ak4114. The only difference I got was:
$ diff ~/Audiophile192-proc-a.txt ~/Audiophile192-proc-b.txt 90c90
< MT05 : 0x08
MT05 : 0x00
I printk'ed a message in ap192_ak4114_init() and it's definitely being called.
I see, ak4114 support in revo.c is incomplete. ak4114 controls incl. the proc file are never built. Please try the following patch (applicable to clean git checkout):
diff --git a/sound/pci/ice1712/revo.c b/sound/pci/ice1712/revo.c index 7641080..3f39c42 100644 --- a/sound/pci/ice1712/revo.c +++ b/sound/pci/ice1712/revo.c @@ -35,6 +35,7 @@ struct revo51_spec { struct snd_i2c_device *dev; struct snd_pt2258 *pt2258; + struct ak4114 *ak4114; };
static void revo_i2s_mclk_changed(struct snd_ice1712 *ice) @@ -487,10 +488,10 @@ static int ap192_ak4114_init(struct snd_ice1712 *ice) ap192_ak4114_read, ap192_ak4114_write, ak4114_init_vals, ak4114_init_txcsb, - ice, &ak); + ice, &spec->ak4114); /* AK4114 in Revo cannot detect external rate correctly. * No reason to stop capture stream due to incorrect checks */ - ak->check_flags = AK4114_CHECK_NO_RATE; + spec->ak4114->check_flags = AK4114_CHECK_NO_RATE;
return 0; /* error ignored; it's no fatal error */ } @@ -562,6 +563,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 +601,13 @@ 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); + /* only capture SPDIF over AK4114 */ + spec = ice->spec; + err = snd_ak4114_build(spec->ak4114, NULL, + ice->pcm->streams[SNDRV_PCM_STREAM_CAPTURE].substream); if (err < 0) - return err; + return err; + break; } return 0;
Thanks,
Pavel.
On 30.1.2013 11:26, Pavel Hofman wrote:
On 29.1.2013 20:14, Jonas Petersen wrote:
Am 29.01.2013 10:39, schrieb Pavel Hofman:
I did that with no success. Same behaviour, no change, still no ak4114. The only difference I got was:
$ diff ~/Audiophile192-proc-a.txt ~/Audiophile192-proc-b.txt 90c90
< MT05 : 0x08
MT05 : 0x00
I printk'ed a message in ap192_ak4114_init() and it's definitely being called.
I see, ak4114 support in revo.c is incomplete. ak4114 controls incl. the proc file are never built. Please try the following patch (applicable to clean git checkout):
Sorry, of course
err = snd_ak4114_build(ice->spec->ak4114, NULL,
instead of
spec = ice->spec;err = snd_ak4114_build(spec->ak4114, NULL,
Pavel.
Am 30.01.2013 11:26, schrieb Pavel Hofman:
On 29.1.2013 20:14, Jonas Petersen wrote:
Am 29.01.2013 10:39, schrieb Pavel Hofman:
I did that with no success. Same behaviour, no change, still no ak4114. The only difference I got was:
$ diff ~/Audiophile192-proc-a.txt ~/Audiophile192-proc-b.txt 90c90
< MT05 : 0x08
MT05 : 0x00
I printk'ed a message in ap192_ak4114_init() and it's definitely being called.
I see, ak4114 support in revo.c is incomplete. ak4114 controls incl. the proc file are never built. Please try the following patch (applicable to clean git checkout):
Pavel, I applied your patch (including the correction in the other post). It did not work out of the box. I had to do a lot of debugging and changes to it to make it compile and then more of that fun to make it not crash alsa. One of the problems was that ice->spec is initialized in revo51_i2c_init(), but it is never called with the ap192. So I copied the initialization to ap192_ak4114_init(). I'll attach a patch of my final version.
When it finally compiled and was running, I had an ak4114 file in proc.
Unfortunately it's full of 0x00's:
/proc/asound/Audiophile192/ak4114:
0x00 = 0x00 0x02 = 0x00 [...] 0x1e = 0x00 0x1f = 0x00
(32 lines total)
There is also no change in the spdif capture behaviour.
Btw. before all of that it took me already some time to make the patch working. Pasting patches in the mail body converts tabs to spaces and also breaks long lines. I can use -l but still it messes up the original content. Is it bad to attach .patch files to mails in this list?
Ok, now I need some help regarding the git sources. I applied all this to my alsa-driver source that I got from here:
ftp://ftp.suse.com/pub/people/tiwai/snapshot/alsa-driver-snapshot.tar.gz
This is so far the only source that I was able to compile. The 1.0.25 release source won't compile with my ubuntu 12.10 (symbol errors). The alsa-compile.sh from http://www.alsa-project.org/main/index.php/Driver_Compilation will also complain about some missing stuff. The git stuff was confusing me a bit. Do I need alsa-kernel or alsa-driver? Or both? The alsa-driver (branch 'release') complains about missing alsa-kernel. But alsa-kernel is a huge package. Is that really necessary?
This snapshot package has some nice ./configure and will make and make install against the ubuntu kernel-headers quite smoothly. So I was using this all the time.
How do I create (or get) a package that compiles against the kernel-headers from my distribution?
- Jonas
On 31.1.2013 01:29, Jonas Petersen wrote:
Am 30.01.2013 11:26, schrieb Pavel Hofman:
On 29.1.2013 20:14, Jonas Petersen wrote:
Pavel, I applied your patch (including the correction in the other post). It did not work out of the box. I had to do a lot of debugging and changes to it to make it compile and then more of that fun to make it not crash alsa.
Sorry, I did not test any compilation/running. The changes were rather simple though. Thanks for sorting out.
When it finally compiled and was running, I had an ak4114 file in proc.
Unfortunately it's full of 0x00's:
/proc/asound/Audiophile192/ak4114:
0x00 = 0x00 0x02 = 0x00 [...] 0x1e = 0x00 0x1f = 0x00
(32 lines total)
There is also no change in the spdif capture behaviour.
OK, it looks we have a problem in communication with the chip. IMO the 4wire_start and 4wire_finish code is incorrect. As chip-select it takes VT1724_REVO_CS1, but for ak4114 it should be VT1724_REVO_CS3 (as defined in revo.h)
IMO the two methods should be: static unsigned int ap192_4wire_start(struct snd_ice1712 *ice) { unsigned int tmp;
snd_ice1712_save_gpio_status(ice); tmp = snd_ice1712_gpio_read(ice); tmp |= VT1724_REVO_CCLK; /* high at init */ tmp |= VT1724_REVO_CS0; tmp &= ~VT1724_REVO_CS3; snd_ice1712_gpio_write(ice, tmp); udelay(1); return tmp; }
static void ap192_4wire_finish(struct snd_ice1712 *ice, unsigned int tmp) { tmp |= VT1724_REVO_CS0; tmp |= VT1724_REVO_CS3; snd_ice1712_gpio_write(ice, tmp); udelay(1); snd_ice1712_restore_gpio_status(ice); }
Provided that VT1724_REVO_CS0 is chip-select for AK4358 DAC and VT1724_REVO_CS3 chip-select for AK4114. The AK5385 ADC has no control.
IMO the ak4xxx config section should use VT1724_REVO_CS3 instead of VT1724_REVO_CS1 too:
static struct snd_ak4xxx_private akm_ap192_priv = { .caddr = 2, .cif = 0, .data_mask = VT1724_REVO_CDOUT, .clk_mask = VT1724_REVO_CCLK, .cs_mask = VT1724_REVO_CS0 | VT1724_REVO_CS3, .cs_addr = VT1724_REVO_CS3, .cs_none = VT1724_REVO_CS0 | VT1724_REVO_CS3, .add_flags = VT1724_REVO_CCLK, /* high at init */ .mask_flags = 0, };
If I am not mistaken VT1724_REVO_CS1 is not used on ap192 at all. Is that correct?
Sorry for not using proper patches but I cannot test the result anyway.
Thanks,
Pavel.
Am 31.01.2013 11:33, schrieb Pavel Hofman:
OK, it looks we have a problem in communication with the chip. IMO the 4wire_start and 4wire_finish code is incorrect. As chip-select it takes VT1724_REVO_CS1, but for ak4114 it should be VT1724_REVO_CS3 (as defined in revo.h)
IMO the two methods should be: static unsigned int ap192_4wire_start(struct snd_ice1712 *ice) { unsigned int tmp;
snd_ice1712_save_gpio_status(ice); tmp = snd_ice1712_gpio_read(ice); tmp |= VT1724_REVO_CCLK; /* high at init */ tmp |= VT1724_REVO_CS0; tmp &= ~VT1724_REVO_CS3; snd_ice1712_gpio_write(ice, tmp); udelay(1); return tmp; }
Btw. is it really intended that CS0 is set and CS3 is unset in 4wire_start? (In 4wire_finish CS0 is set again.)
static void ap192_4wire_finish(struct snd_ice1712 *ice, unsigned int tmp) { tmp |= VT1724_REVO_CS0; tmp |= VT1724_REVO_CS3; snd_ice1712_gpio_write(ice, tmp); udelay(1); snd_ice1712_restore_gpio_status(ice); }
Provided that VT1724_REVO_CS0 is chip-select for AK4358 DAC and VT1724_REVO_CS3 chip-select for AK4114. The AK5385 ADC has no control.
CS0 (0x10) is GPIO4 and CS3 (0x80) is GPIO7, right?
Physically GPIO7 goes to CSN (pin 35) of the AK4114, as I confirmed before.
GPIO4 goes to CSN (pin 21) of the AK4358. I just did a physical check to confirm that also!
So I guess (hope) that would confirm that "VT1724_REVO_CS0 is chip-select for AK4358 DAC and VT1724_REVO_CS3 chip-select for AK4114"
One question: What do you mean by "The AK5385 ADC has no control."? Is that by nature of the chip?
IMO the ak4xxx config section should use VT1724_REVO_CS3 instead of VT1724_REVO_CS1 too:
static struct snd_ak4xxx_private akm_ap192_priv = { .caddr = 2, .cif = 0, .data_mask = VT1724_REVO_CDOUT, .clk_mask = VT1724_REVO_CCLK, .cs_mask = VT1724_REVO_CS0 | VT1724_REVO_CS3, .cs_addr = VT1724_REVO_CS3, .cs_none = VT1724_REVO_CS0 | VT1724_REVO_CS3, .add_flags = VT1724_REVO_CCLK, /* high at init */ .mask_flags = 0, };
If I am not mistaken VT1724_REVO_CS1 is not used on ap192 at all. Is that correct?
That woud be GPIO5, right? I'm not sure. If this is the case, wouldn't that pin not be tied to some level (high or low)?
Sorry for not using proper patches but I cannot test the result anyway.
No problem. I tested, but still no succes.. :(
I noticed one more thing:
VT1724_REVO_CDIN (GPIO2) goes to CDTO and VT1724_REVO_CDOUT (GPIO3) goes to CDTI of the AK4114. "IN" is "O" and "OUT" is "I". Ist that correct? I tried to swap them once but that didn't help either.
- Jonas
:-)
I've got some progress here. The AK4114_ADDR was wrong. I changed it from 0x02 to 0x00 (according to datasheet).
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!
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.
Here is some content of the ak4114:
/proc/asound/Audiophile192/ak4114
0x00 = 0x0f 0x01 = 0x70 0x02 = 0x80 0x03 = 0x49 0x04 = 0x00 0x05 = 0x00 0x06 = 0x10 0x07 = 0x10 0x08 = 0x45 0x09 = 0x02 0x0a = 0x2c 0x0b = 0x00 0x0c = 0x00 0x0d = 0x41 0x0e = 0x02 0x0f = 0x2c 0x10 = 0x00 0x11 = 0x00 0x12 = 0x00 0x13 = 0x00 0x14 = 0x00 0x15 = 0x00 0x16 = 0x00 0x17 = 0x00 0x18 = 0x00 0x19 = 0x00 0x1a = 0x00 0x1b = 0x00 0x1c = 0x00 0x1d = 0x00 0x1e = 0x00 0x1f = 0x00
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.
The Clock Source seems to be PLL (CM1-0 = 0,0).
I'll keep on debugging.
- Jonas
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.
Am 02.02.2013 11:44, schrieb Pavel Hofman:
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).
Yeah, I found the right combination, it's OCKS0=1,OCKS1=0. Now the spdif input works, thank you!
I wonder why there is no level controls for the analog input (e.g. in alsamixer). Is that because the "AK5385 ADC chip has no control"? The ESI Juli doesn't have an analog input level control as well.
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?
Ok, to make it clear, on the ap192 the FSx registers are always at their default (0001). So far I've never seen them on any other value. Only the corresponding Channel Status bits do change.
Well, I guess by default snd_ak4114_rate_get should still interpret the FSx bits. Other cards might work as expected (see 'Observation C' below). In the case of the ap192 it might make sense to read the Channel Status. Maybe it needs a flag that gets set on card initializing indicating what should be used?
But, after all it seems there is still something obscure in the rate detection. Because while watching the ak4114 registers when switching sample rates I made the following observations:
Observation A:
RME Multiface spdif out goes to AP192 spdif in. In Linux the FSx bits are alwas "0001" and the Channel Status bis are set according to sample rate and mode (consumer/professional).
Observation B:
ESI Julia spdif out goes to AP192 spdif in. (Recall that in windows the AP192 _does_ detect sample rate changes!) In Linux the FSx bits are alwas "0001" and the Channel Status bis are (almost) always _all_ "0". It seems the ESI does not send Channel Status at all (could it be the misconfiguration of the ESI?). It looks like this:
0x07 = 0x10 (00010000) [FS3,2,1,0 etc.] 0x08 = 0x00 (00000000) [CS0] 0x09 = 0x00 (00000000) [CS1] 0x0a = 0x00 (00000000) [CS2] 0x0b = 0x00 (00000000) [CS3] 0x0c = 0x00 (00000000) [CS4]
There is one strange exception. When I switch the output to spdif in the (I think it is) pulseaudio GUI. Then register 0x09 will be '00000010' for 5 second and switch back to '00000000'. When I play the test sound, then register 0x09 _and_ register 0x0b will be '00000010' for 5 second and switch back. Other than that the Channel Status does not change.
Now, how is the windows driver detecting the rate if there is a) no crystal in there and b) no Channel Status available? Might it be the clock being on PLL (I'm not realy aware of what that means right now)?
One thing might be of interest here: when switching the sample rates, register 0x06 does the following: Bit 0, bit 4 and flash to 1 for a short moment and back to zero (sometimes 2 times in a row).
0x06 = 0x11 (00010001) [flash to 1] 0x06 = 0x00 (00000000) [and back to 0]
Bit 0 is "PAR: Parity Error or Biphase Error Status" Bit 4 is "PLL Lock Status" (1 being "Out of Lock")
Observation C (this is regarding ESI Juli):
dbx 376 tube channel strip spdif out goes to ESI Juli spdif in. The FSx bits in register 0x07 of ESI Juli's AK4114 _do_ change on different sample rates. They do not match those in the datasheet though:
1000 - 44kHz (expected: 0000) 1010 - 48kHz (expected: 0010) 1100 - 88.2kHz (expected: 1000) 1110 - 96kHz (expected: 1010)
So maybe this is another symptom of the ESI's misconfiguration?
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.
Ok, why not adding a control for that. But first explain something to me. I see these 15 control definitions "snd_ak4114_iec958_controls[]" in ak4114.c. How are they accessed? Where can I read for example the "IEC958 External Rate" value? In the proc dir they do not show up. Neither at Juli nor at AP192. Are these only API functions?
- Jonas
On 2.2.2013 23:47, Jonas Petersen wrote:
Am 02.02.2013 11:44, schrieb Pavel Hofman:
Yeah, I found the right combination, it's OCKS0=1,OCKS1=0. Now the spdif input works, thank you!
Congrats.
I wonder why there is no level controls for the analog input (e.g. in alsamixer). Is that because the "AK5385 ADC chip has no control"? The ESI Juli doesn't have an analog input level control as well.
Right, ak5385 offers no attenuation control.
Ok, to make it clear, on the ap192 the FSx registers are always at their default (0001). So far I've never seen them on any other value. Only the corresponding Channel Status bits do change.
OK
Well, I guess by default snd_ak4114_rate_get should still interpret the FSx bits. Other cards might work as expected (see 'Observation C' below). In the case of the ap192 it might make sense to read the Channel Status. Maybe it needs a flag that gets set on card initializing indicating what should be used?
But, after all it seems there is still something obscure in the rate detection. Because while watching the ak4114 registers when switching sample rates I made the following observations:
Observation A:
RME Multiface spdif out goes to AP192 spdif in. In Linux the FSx bits are alwas "0001" and the Channel Status bis are set according to sample rate and mode (consumer/professional).
That means the RME driver configured the SPDIF-out preamble correctly. In alsa e.g. using the iecset tool.
Observation B:
ESI Julia spdif out goes to AP192 spdif in. (Recall that in windows the AP192 _does_ detect sample rate changes!) In Linux the FSx bits are alwas "0001" and the Channel Status bis are (almost) always _all_ "0". It seems the ESI does not send Channel Status at all (could it be the misconfiguration of the ESI?). It looks like this:
0x07 = 0x10 (00010000) [FS3,2,1,0 etc.] 0x08 = 0x00 (00000000) [CS0] 0x09 = 0x00 (00000000) [CS1] 0x0a = 0x00 (00000000) [CS2] 0x0b = 0x00 (00000000) [CS3] 0x0c = 0x00 (00000000) [CS4]
There is one strange exception. When I switch the output to spdif in the (I think it is) pulseaudio GUI. Then register 0x09 will be '00000010' for 5 second and switch back to '00000000'. When I play the test sound, then register 0x09 _and_ register 0x0b will be '00000010' for 5 second and switch back. Other than that the Channel Status does not change.
I do not know in windows, but in alsa the SPDIF bits can be set explicitly by user space. See the AESx params in /usr/share/alsa/pcm/iec958.conf , /usr/share/alsa/cards/ICE1724.conf (setting the alsa control "IEC958 Playback Default"). ICE1724 datasheet says the integrated SPDIF transmitter should set the corresponding SPDIF bits (reg MT3C) automatically:
quote
These bits declare the S/PDIF transmitter clock rate (64*fs) in the Channel Status Byte 3, low nibble if Consumer mode (MT3C_0 = 0) and Byte 0 (bits 7-6) and Byte 4 (bits 6-3) if Professional mode (MT3C_0 = 1). It will be set automatically by MT01 low nibble if master. In slave mode (MT01_4 = 1), to display the correct sampling rate, it must be written to reflect the external clock recovered.
endquote
Now, how is the windows driver detecting the rate if there is a) no crystal in there and b) no Channel Status available? Might it be the clock being on PLL (I'm not realy aware of what that means right now)?
I do not know, are you sure there is really no channel status available?
One thing might be of interest here: when switching the sample rates, register 0x06 does the following: Bit 0, bit 4 and flash to 1 for a short moment and back to zero (sometimes 2 times in a row).
0x06 = 0x11 (00010001) [flash to 1] 0x06 = 0x00 (00000000) [and back to 0]
Bit 0 is "PAR: Parity Error or Biphase Error Status" Bit 4 is "PLL Lock Status" (1 being "Out of Lock")
Observation C (this is regarding ESI Juli):
dbx 376 tube channel strip spdif out goes to ESI Juli spdif in. The FSx bits in register 0x07 of ESI Juli's AK4114 _do_ change on different sample rates. They do not match those in the datasheet though:
1000 - 44kHz (expected: 0000) 1010 - 48kHz (expected: 0010) 1100 - 88.2kHz (expected: 1000) 1110 - 96kHz (expected: 1010)
So maybe this is another symptom of the ESI's misconfiguration?
When I tested the driver of Juli the values worked correctly. Let's figure out AP192 first and then attack Juli :)
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.
Ok, why not adding a control for that. But first explain something to me. I see these 15 control definitions "snd_ak4114_iec958_controls[]" in ak4114.c. How are they accessed? Where can I read for example the "IEC958 External Rate" value? In the proc dir they do not show up. Neither at Juli nor at AP192. Are these only API functions?
see output of amixer contents. They are defined as PCM-type controls (not MIXER type and do not apper e.g. in alsamixer.
Regards,
Pavel.
Ok, let's keep this going... I'll post a patch of the current state that I got (for the M-Audio Audiophile 192). I think it's already worth a review/commit since spdif input is now working properly.
There is still potential for more improvements, concerning the sample frequency detection.
Am 04.02.2013 17:56, schrieb Pavel Hofman:
On 2.2.2013 23:47, Jonas Petersen wrote:
Now, how is the windows driver detecting the rate if there is a) no crystal in there and b) no Channel Status available? Might it be the clock being on PLL (I'm not realy aware of what that means right now)?
I do not know, are you sure there is really no channel status available?
Quite sure. It seems to be an ESI Juli phenomenon. I did plug my several devices into the AP192 spdif input while observing the channel status. The ESI is not sending any channel status, the others are...
But, as you suggested let's address the Juli later, maybe in a separate thread.
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.
Ok, why not adding a control for that. But first explain something to me. I see these 15 control definitions "snd_ak4114_iec958_controls[]" in ak4114.c. How are they accessed? Where can I read for example the "IEC958 External Rate" value? In the proc dir they do not show up. Neither at Juli nor at AP192. Are these only API functions?
see output of amixer contents. They are defined as PCM-type controls (not MIXER type and do not apper e.g. in alsamixer.
Thanks, found it. Would that help in finding out how the card is detecting rate without any clue?
I once read somwhere about a kind of hackish way of detecting sampling frequency by just capturing some samples (at a fixed rate) and calculating by comparing what you get to what you're supposed to get (or something like that, don't remember exactly). Can't find it anywhere right now though.
Might it be that the windows driver is doing something like that as a fallback (or even always) when there is no channel status?
I'd like to once send the card a - let's say - 44.1 kHz signal with a - let's say - 96 kHz info in the channel status and see what the windows driver says. :)
- Jonas
On 23.2.2013 23:13, Jonas Petersen wrote:
Ok, why not adding a control for that. But first explain something to me. I see these 15 control definitions "snd_ak4114_iec958_controls[]" in ak4114.c. How are they accessed? Where can I read for example the "IEC958 External Rate" value? In the proc dir they do not show up. Neither at Juli nor at AP192. Are these only API functions?
see output of amixer contents. They are defined as PCM-type controls (not MIXER type and do not apper e.g. in alsamixer.
Thanks, found it. Would that help in finding out how the card is detecting rate without any clue?
Hopefully. It shows you values of all ak4114 registers. The same information as available to the windows driver.
Now can you please look at the regs if you can spot any hint of the incoming sample rate from Juli (specifically the spdif channel status regs and the incoming fs regs)? Thanks.
I once read somwhere about a kind of hackish way of detecting sampling frequency by just capturing some samples (at a fixed rate) and calculating by comparing what you get to what you're supposed to get (or something like that, don't remember exactly). Can't find it anywhere right now though.
Might it be that the windows driver is doing something like that as a fallback (or even always) when there is no channel status?
Well, it is certainly feasible but I very much doubt the driver does it.
I'd like to once send the card a - let's say - 44.1 kHz signal with a - let's say - 96 kHz info in the channel status and see what the windows driver says. :)
Take a look at the iecset utility. It sets the IEC958 channel status bits of the spdif transmitter (e.g. of your Juli or AP192). I would start a 44.1kHz stream and try to rewrite the values using iecset. You can check in regs list of your ice1724 card in /proc/asound/yourcard/ice1724 if the change took place (register MT3C). The playback may lock the IEC958 channel status controls. If it is the case, try to comment out the IEC958 Playback Default "lock true" in /usr/share/alsa/cards/ICE1724.conf.
Instead of iecset you can use amixer to manipulate IEC958 Playback Default directly, but you will have to figure out correct bit values.
Good luck and thanks for the patch you sent :)
Pavel.
Hi Jaroslav,
I think I found it. I followed the spdif in and it leads to U19 which is an AKM AK4114VQ ("High Feature 192kHz 24bit Digital Audio Interface Transceiver"). It's the topmost of the very right of the card (below the "M-AUDIO" lettering).
There is code for this chip in the driver-source (i2c/other/ak4114.c) and it's also referenced in the code for the Audiophile 192 (see revo.c and revo.h).
Or do you think there's another chip involved?
- Jonas
2013/1/26 Jaroslav Kysela perex@perex.cz
I believe that there must be a S/PDIF receiver IC somewhere on the board and this IC may be wrongly configured. This IC is not handled in the current ALSA driver at all. Could you look to your board and check the used chips? From pictures on internet, a suspicious IC is in the middle of top on this PCI card. The AKM IC's are for analog audio outputs.
The ICE1724 chip has only serial SPDIF input and SPDIF input clock pins. The input samples should be copied to the DMA without any modifications (no volume control etc.).
Jaroslav-- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project; Red Hat, Inc.
participants (3)
-
Jaroslav Kysela -
Jonas Petersen -
Pavel Hofman