[alsa-devel] Correct use of ak4114.c?

dustin at seznam.cz dustin at seznam.cz
Sun Apr 1 23:09:01 CEST 2007

Hi Takashi
>  > BTW, what is difference between professional and spdif pcms? Is it
>  > only about digital format (like professional/consumer in iecset)?
>  > Sorry for stupid questions, but I do not know which pcm to use. 
>  VT1724 has seperate DMAs for the analog and the SPDIF streams while 
>  ICE1712 has only one for both (mixed up).
>  Confusingly the analog PCM is named "professional" there because it
>  was called so in ice1712 driver, and vt1724 driver is derived from
>  ice1712 driver.  ICE1712 has two analog connections modes, consumer
>  mode (usually via ac97) and professional mode (via i2s).

Uff, that is a lot of background knowledge. Would it be possible to put this explanation into ice1724.c code? It would definitely help newcomers. Thanks a lot.

>  > Would I get to playback/capture substreams e.g. using
>  > ice->pcm_pro->streams[0/1]->substream at the end of
>  > snd_vt1724_probe? I understand I could probably find this
>  > information in alsa documentation.
>  The build_controls callback is called after creation of PCMs.
>  So, you can call it there.  The proposed fix for Juli is below.
>  Can any Juli users test the latest HG version with this patch?

I tested the code with prodigy192 and my current ak4114 code. I used ice->pcm stream instead of ice->pcm_pro 
since I guess that is the one for SPDIF data. 

Probing the module produced error -16 (EBUSY). Analysis showed duplicity of control item 
SNDRV_CTL_NAME_IEC958("",PLAYBACK,DEFAULT) defined in ice1724.c (snd_vt1724_spdif_default) as well as ak4114.c . Upon removing the control from ak4114.c (and adjusting AK4114_CONTROLS) the module loaded correctly and all the new PCM controls were available in amixer.

I think the problem is that the  ak4114 support assumes both SPDIF OUT and IN functions are used, whereas ice1724 support assumes SPDIF-OUT is handled by ice1724, leaving only SPDIF-IN to other chips. At least with Prodigy192 + MI/ODI/O that is the case in reality too (ak4114 spdif-out capability is not used, signal goes from ice1724 directly to output buffers on the add-on card).

What solution would you suggest? I guess a solution would be to check for duplicity before adding new controls, or perhaps continue after hitting error EBUSY in snd_ctl_add.

Best regards, 


More information about the Alsa-devel mailing list