Perhaps a solution could involve splitting ak4114 support into spdif-in and spdif-out. When creating ak4114 we could specify which part should be active. Default would be both parts in order to keep existing funcionality. The change would only concern controls definition and corresponding snd_ctl_notify calls anyway.
Thanks.
Pavel.
------------ Původní zpráva ------------ Od: dustin@seznam.cz Předmět: Re: [alsa-devel] Correct use of ak4114.c? Datum: 01.4.2007 23:09:13
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,
Pavel. _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel