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

[Takashi Iwai]

At Sun, 01 Apr 2007 23:09:01 +0200 (CEST),
dustin at seznam.cz wrote:
> 
> 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. 

A patch is welcome ;)


> >  > 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. 

Then the problem is that it passed the playback substream to
snd_ak4114_build().  I guess passing NULL there instead should work.


Takashi